hi lothar, really, you should know the subject deeper before making absolute statements, for otherwise you run the risk of being wrong and just looking silly.
multi-threading is primitive with GTK? are you crazy? if you refer to drawing with Pango, then yes, this must be done in the main thread (when using X11 backend), but locking all of GTK? not true. and anyway, how many different things can an application draw at the same time requiring multi-threadable drawing that will make all the difference? Cairo replaced Pango long ago and should be used in newly written code (imho). if multi-threaded drawing makes a difference then this is the way to go, i.e., a solution exists, so why concentrate on the limitations of past implementations that are no longer recommended? as far as general multi-threading is concerned, you have no idea what you're talking about. i make use of multi-threading in my GUI's extensively (querying the number of CPU's i have available at program startup, using this info throughout). I have background threads that do all kinds of work, both not related to drawing, as well as drawing preparation. for example, i have one screen of nine panels of by-hand drawings, each requiring its own data to be retrieved from a DB. all calls to the DB are done in separate threads, executing simultaneously, i.e., in parallel. all calls to my DB can be made synchronously or asynchronously. in other words, i can take advantage of all programming techniques available where multi-threading is concerned and feel not limited one iota. in another application, i'm using GIO to parse several I/O streams (stdout, stderr, more) at the same time, sending the data coming from each to different destinations depending on a lot of differing parameters. this is done in a separate thread running its own main loop. and in yet another, i use a separate thread to manage time-restricted execution of a server-side process, i.e., a separate thread allows me to easily engage in program scheduling. throw in GLIB and you're basically guaranteed to be able to achieve whatever idea you can come up with. just because this doesn't happen in your case doesn't really say much about GTK per se, but more about your (lack of) knowledge of it. but i kind of don't understand something. if it's all so bad, why aren't you just using something else? since i assume that if that were the case you wouldn't feel the need to post here, leaving the rest of us in peace to not have to take the time to correct your mis-statements? on the other hand, i like defending GTK and GLIB, gives me the opportunity to show off all the fancy things one can do with it. i wouldn't use anything else. cheers, richard On Wed, Jun 1, 2011 at 5:09 AM, Lothar Scholz <llot...@web.de> wrote: > Hello Gang, > > Wednesday, June 1, 2011, 9:44:02 AM, you wrote: > > GC> Hi Lothar, > > GC> Thank you for your information! Maybe they are not so bad for me. My > GC> app has a simple GUI, and uses a drawing area to display text with > GC> some decorations. If my app can work fine on windows, linux and OSX > GC> without too many hacking efforts, I'll be satisfactory. Actually, my > GC> main concerns are about multithreading (I chose to use boost::thread > GC> and boost::threadpool) and gtkmm (it seems to be incomplete; not sure > GC> about its quality). > > If you want multithreading in the GUI it will be very primitive with > GTK. You have to lock the complete GTK system, this means you will > never ever get a speed increase. On my CPU the drawing can never be > more then 12,5% CPU Load - thats what i call bad. > > You can move away from Pango and only use Cairo and the toy text API > of cairo which seems to be multithread safe. Or wait a half year, > somebody just started working on MT-safe Pango but it takes time until > tested, proofed to work and the patch is included the main code line. > > > -- > Best regards, > Lothar mailto:llot...@web.de > > _______________________________________________ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list >
_______________________________________________ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
