discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Graphic flicker in GNUStep


From: Banlu Kemiyatorn
Subject: Re: Graphic flicker in GNUStep
Date: Fri, 01 Dec 2006 18:26:12 +0700
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

David Espada wrote:
 Hello, group.

 This is the first time I write here. Excuse my poor english, I am not
 native speaker.

 I have been probing GNUStep in Debian Linux Testing (Etch). I can't
 decide about quality because of two reasons:

        - Applications seems to be very pedestrian, except development
          applications, like Gorm, ProjectCenter... But that is a known
          issue and I don't like raise it again.

        - I feel an extrange flicker in graphics that doesn't exist in
          other graphic toolkits (like Gtk or Qt). I thougt that GNUStep
          was lightweight soft, but when you resize a window or change
          virtual desktop, it seems to flicker excesively, as if it
          weight too much.
I think these are known issues. I don't have a certain idea of how to
solve these problems. Though, I have some opinions.

First I remind you, GNUstep's drawing is slow comparing with the other systems because it relies on PostScript like display engine which is slower than the others' drawing method but that's a trade-off with WYSIWYG. (GTK+ uses cairo too, though we are pretty more upto it than GTK+, since GNUstep allow you to do much more advance things than GTK+'s API do)

And so that lead to another problem that when resizing window, since that trigger a few intensive drawings. One way around this is by compressing X11's configure notify event so drawings were not requested at every bit of resizing. This was addressed long time ago, but it was not interesting enough so nobody fix that probably because
they are using Window Maker that doesn't allow the kind of windows resizing.
If you are interested, you can fix that yourself by fixing XGServerEvent.m, somewhere around ConfigureNotify. The same kind of compression was done for MotionNotify by someone who never use such apps that need more granular mouse tracking eg. gimp ;) (This issue was also addressed, long time ago, but again it was also not interesting enough to get fixed)

Another way is by using xdbe (x11 double buffering extension)
but that would waste more memory. That wouldn't make drawing faster, just
updating in a smoother manner _and_ that isn't solving the window resizing issue
but may solve a synchronizing problem that happen on every mode I tried
to create an NSWindow which cause flickering when drawing intensively.

Another idea is to allow "full stop operation" and split the drawing code into
a different thread which stacks drawing operations from the client and can
discard some operation not neccessary. So the drawing code/app can tell
the drawing backend using the full stop op that an ROI will be completely
covered by some following ops. I also expected this model to very work well as
a server/client over IPC.

BTW, In near future, the drawing method can be highly accelerated by using
GPU, for example, if our cairo glitz backend actually work.

 Is there a known reason for the second point? Is is very annoying and
 gives GNUStep an amateurish feeling.

 Thanks for your hard work.

                                                        David
_______________________________________________
Discuss-gnustep mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnustep





reply via email to

[Prev in Thread] Current Thread [Next in Thread]