[es] - brzina MFC vs FLTK vs WIN32 API vs others

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
*.nat-pool.po.sbb.co.yu.

Jabber: xfiles@elitesecurity.org

+638 Profil

Re: brzina MFC vs FLTK vs WIN32 API vs others

^{10.01.2006. u 11:36 - pre 222 meseci}

Sto se tice MFC-a i API-ja stvar je sledeca:

Prvo, API je zbirka raznih funkcija koje koristi Windows.

MFC nije nista drugo nego lepse upakovan API, odnosno kako bi to (otprilike) rekli
na engleskom jeziku: "MFC is a wrapper arround API". Isto je i sa OWL, VCL,...
(Borlandovi wrapperi).

Prema tome MFC moze biti isto ili manje brz od API-ja.

Sto se tice FLTK-a, to je cross-platform biblioteka i sa njom nemam iskustava, ali
pretpostavljam da je situacija slicna.

Takodje, sto je sistem 'jednostavniji' to je i brzi jer ima manje stvari da uradi. Npr:
Najbrza stvar koji sam nekada bio probao je Win 3.11 na racunaru sa 300MHz. Mogu
da zamislim kako bi to danas izgledalo, sa ovolikim megahercima. Tu su se prozori
prosto lepili po Desktopu.

P.S.

EDIT:

Neke moje kolege koje se bave nekim slozenim matematickim proracunima (konacni
elementi) kazu da znatno brze rade programi koju su uradjeni na FORTRAN-u nego
na C-u ?! Verovatno se radi o tome da FORTRAN ima manje "slojeva" da probije dok
dodje do samog masinskog izracunavanja.

_{[Ovu poruku je menjao X Files dana 10.01.2006. u 14:35 GMT+1]}

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
*.dyn.optonline.net.

+6 Profil

Re: brzina MFC vs FLTK vs WIN32 API vs others

^{10.01.2006. u 13:52 - pre 222 meseci}

Citat:

X Files: Neke moje kolege koje se bave nekim slozenim matematickim proracunima (konacni
elementi) kazu da znatno brze rade programi koju su uradjeni na FORTRAN-u nego
na C-u ?! Verovatno se radi o tome da FORTRAN ima manje "slojeva" da probije dok
dodje do samog masinskog izracunavanja.

Jok, u pitanju je pre svega "aliasing". Ukratko, u C-u više pointera mogu da pokazuju na istu memoriju, i onda kompajler nije u mogućnosti da izvede optimizacije koje bi bile moguće da ovo nije slučaj.

IOCC

Odgovor na temu

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
*.nat-pool.po.sbb.co.yu.

Jabber: xfiles@elitesecurity.org

+638 Profil

Re: brzina MFC vs FLTK vs WIN32 API vs others

^{10.01.2006. u 13:59 - pre 222 meseci}

Da... onda je to to...

Odgovor na temu

leka
Dejan Lekić
senior software engineer, 3Developers
Ltd.
London, UK

Član broj: 234
Poruke: 2534
..81.static.gus.vf.siwnet.net.

Sajt: dejan.lekic.org

+2 Profil

Re: brzina MFC vs FLTK vs WIN32 API vs others

^{31.03.2006. u 16:06 - pre 219 meseci}

Tesko da je MFC brzi od FLTK-a... MFC je provereno/poznato spor, glomazan, ali robustan framework.
Na Windows platformi FLTK poziva direktno GDK i Win32 API. Kad se uzme u obzir to da FLTK ne koristi kompletan STDC++, vec samo SUPC++, i kada se uzme u obzir da FLTK u 99% slucajeva koristi samo STDC (znaci cisti C) onda postaje jasno zasto u nazivu ima ono "Fast" i "Light".
Neko ce pitati "zasto se onda svrstava u C++ toolkit?" - zato sto FLTK koristi C++ OO osobine - namespace (FLTK 2.0, 1.x ne koristi namespace), klase (sve je jasno zaokruzeno i lepo enkapsulirano u jasne klase - primera radi: fltk::Widget, fltk::Window, fltk::Symbol, fltk::Image, ...), new i delete operatore (ovo je zapravo ono sto dolazi u SUPC++-u :), anonimne enum-e...
Zasto se nije odmah u startu pocelo sa STDC++-om (nekadasnji STL)? - Zato sto u vreme kada je nastao FLTK STL nije uopste bio portabilan, iako su mnogi mislili da jeste, raznorazne STL implementacije sadrzavale su puno razlika, sto je otezavalo koriscenje STL-a na vise platformi... Danas je situacija drugacija, STL je postao deo C++ standarda (zato mozda neko primecuje da ja nigde ne spominjem STL, vec STDC++) te smo prosle godine glasali za koriscenje STDC++ u FLTK-u. No, do danas nismo poceli koristiti STDC++, najverovatnije zbog inercije. :) FLTK je sladak ovakav kakav jeste. Munjevito brz i jednostavan.
Na adresi http://www.nu6.org/_/src/cpp/index.html imate par primera FLTK 2.0 programa. Ne postoji GUI toolkit koji sa tako malo koda daje isti rezultat.
Primera radi, ovaj programcic

Code:

#include <fltk/run.h>
#include <fltk/Window.h>
#include <fltk/SharedImage.h>

using namespace fltk;

int main(int argc, char **argv)
{
  Window* main_win = new Window(1000,600);
  main_win->image(fltk::pngImage::get("mapbg.png"));
  main_win->end();
  main_win->show(argc, argv);

  return fltk::run();
}

Daje ovaj rezultat: http://www.nu6.org/_/src/cpp/0011.png
Priznacete, impresivno. Za istu aplikaciju u recimo wxWidgets ili QT treba bar duplo vise koda... Da bi se ovakav program napisao u MFC-u... brrr, ne smem ni da pomislim koliko koda treba...

Na kraju jedno upozorenje - primecujem da pokretac teme mesa termine - MFC NIJE WIN32 API! :))) MFC kao i FLTK koristi WIN32 API na Windows-u.

_{[Ovu poruku je menjao leka dana 31.03.2006. u 17:09 GMT+1]}

Dejan Lekic
software engineer, MySQL/PgSQL DBA, sysadmin

Odgovor na temu

Buffy
Stanko Culaja
Sipovo, BiH

Član broj: 45310
Poruke: 312
*.teol.net.

Profil

Re: brzina MFC vs FLTK vs WIN32 API vs others

^{31.03.2006. u 21:40 - pre 219 meseci}

Leka, ako FLTK koristi WIN32 API, zasto dugmadi, liste i ostali objekti totalno drugacije izgledaju od objekata koji su napravljeni pomocu MFC-a? (Izgled prozora je dosta los :( ).
Da li FLTK pravi glavni prozor pomocu CreateWindow(), a dugmadi i dr. objekte crta pomocu HDC-a od glavnog prozora?
Ja sam pokusao da dobijem HWND od dugmeta nekog prozora pomocu sledeceg koda:

Code:

#include <windows.h>

int main(){
    HWND parent=FindWindow(NULL,"prozor");
    if (parent==NULL) return -1;
    HWND child=FindWindowEx(parent,NULL,NULL,"dugme");
    if (child==NULL) return -2;
    return 0;
}

Ako sam ovaj prozor i dugme unutar njega napravio pomocu WINAPI-ja onda mi je funkcija main() vratila 0, sto znaci da je child win, odnosno dugme pronadjeno.
Ako ovo isto napravim u FLTK-u funkcija vraca -2, sto znaci da je prozor pronadjen, ali ne i dugme.
Molim te da mi ovo pojasnis, jer ne bih da gledam u source od FLTK-a :))
Pozdrav!!!

p.s. Cestitam X-Filesu i leki na tituli :)

[email protected]

Odgovor na temu

basicD
Beograd

Član broj: 47449
Poruke: 70
194.106.169.*

+26 Profil

Re: brzina MFC vs FLTK vs WIN32 API vs others

^{31.03.2006. u 23:49 - pre 219 meseci}

Citat:

leka:
Primera radi, ovaj programcic

Mislim da si hteo da kazes da u Qt treba napisati skoro duplo manje koda :

Code:

#include <QtGui>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QLabel label(0);
    label.setPixmap(QPixmap("screenshot.png"));
    label.show();
    return app.exec();
}

Qt ima citav niz prednosti u odnosu na recimo FLTK(mada naravno nemam nista protiv njega cak naprotiv) recimo:

1) - Qt kod je lako citljiv sa izrazito intuitivnim nazivima klasa ,funkcija itd.
[url] http://www.trolltech.com/developer/doc.html [/url]
Mozda sam subjektivan ali mi se cini da je FLTK kod daleko manje pregledan.

2) - Aplikacije kod Qt-a izgledaju nativno na svakoj podrzanoj platformi(Inace od Qt4 GPL licenca je dostupna za Linux,Windows i Mac OS) i Izgled prozora je dosta lepsi nego kod FLTK-a(opet subjektivno ali sta cu :) ).

3) - E sad sto se brzine tice FLTK jeste brzi("Fast" i "Light") ali treba imati u vidu da Qt ima daleko veci broj klasa i podrsku za
sve i svasta(mislim da novije Qt biblioteke imaju preko 500 000 linija koda),FLTK bi isto tako bio sporiji kada bi bilo implementirano sve sto ima Qt( FLTK bi po meni trebalo da ostane ovakav).Mada je pitanje brzine krajnje diskutabilno,recimo
novija KDE okruzenja(bazirana na Qt za one koji ne znaju) su veoma brza(narocito na Slackware-u(Slax-u pogotovo)
i Yoper-u ) ko ne veruje neka proba :).

History, in general, only informs us what bad government is.
Thomas Jefferson

Odgovor na temu

leka
Dejan Lekić
senior software engineer, 3Developers
Ltd.
London, UK

Član broj: 234
Poruke: 2534
..81.static.gus.vf.siwnet.net.

Sajt: dejan.lekic.org

+2 Profil

Re: brzina MFC vs FLTK vs WIN32 API vs others

^{03.04.2006. u 03:07 - pre 219 meseci}

Buffy, FLTK ne sam "crta" svoje widget-e, dakle ne koristi Common Controls. Ovo naravno ima svoje prednosti i mane.

basicD, ono je ipak bio trivijalan primer, i kada se izuzmu include direktive i ako se koristi fltk:: sto eliminise using namespace ispada da za tu trivijalnu QT aplikaciju treba otprilike ista kolicina koda. Kada se gleda na malo komplikovanije aplikacije, razlika u kodu bi najverovatnije bila veca, i pretpostavljam da bi za adekvatnu FLTK aplikaciju trebalo manje koda. Iz iskustva znam da je rezultujuca aplikacija uglavnom manja, i manje zahtevna (resursi). Naravno, QT ovo kompenzuje dobrim, robusnim i opsirnim framework-om.
Ne boj se, ima FLTK sve "fensi" widgete koje ima i QT, samo nisu deo distribucije, vec to rade drugi ljudi (sto tako i treba da bude).

Sto se tice izgleda... FLTK ima mogucnost rada sa temama, koju ne znam zasto, niko ne koristi. Mozda je to navika FLTK programera - ja, i mnogi drugi koje znam, volimo da izgled bude konzistentan, dakle aplikacija izgleda isto na svim platformama.

Neki ce pomisliti da ovde pocinje flame-war QT vs FLTK. Nema potrebe za njega, QT je drasticno popularniji, a FLTK ce zbog svojih osobina uvek imati deo GUI torte. :)

Ko poznaje QT zna dobro da QT nije samo GUI, vec mnogo vise. FLTK ekipa se fokusira samo na ono "GUI". Razlika je najveca, ocigledno, u konceptu. Nama (FLTK timu) nije cilj da radimo general-purpose C++ framework, sa GUIjem koji predstavlja samo jedan delic... General-purpose C++ framework vec postoji, tj. dva - STDC++ i Boost. :)

Sto se tice sta je preglednije... Evo gornjeg FLTK primera u drugom obliku:

Code:

#include <fltk/run.h>
#include <fltk/Window.h>
#include <fltk/SharedImage.h>

using namespace fltk;

int main(int argc, char **argv)
{
  Window win(1000,600);
  win.image(pngImage::get("mapbg.png"));
  win.end();
  win.show();
  return run();
}

Ne vidim nista nepregledno ovde. :)

_{[Ovu poruku je menjao leka dana 03.04.2006. u 04:13 GMT+1]}

Dejan Lekic
software engineer, MySQL/PgSQL DBA, sysadmin

Odgovor na temu