Re: [platform-swt-dev] expose compression

["Steve Northover/OTT/OTI" <Steve_Northover@xxxxxxx>]

Yes, we know this is a problem.  The bug number is 5904.

I'm intimate with Windows WM_PAINT so I know that's a good strategy
but tricky to implement.

I know about XtExposeCompressMultiple but as far as I know this
is for Xt widget implementors which we are not.  I'm not aware of a way
to set this resource after a widget is created other than poking memory.

Steve

Havoc Pennington <hp@xxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 11/15/01 04:10 PM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-swt-dev] expose compression

Hi,

When trying to use the Motif port, I'm noticing that the major
usability problem I'm encountering is the lack of expose
compression. For example, if I drag another window across the Eclipse
window, it will generate a stream of expose events (the "trailing"
effect) and Eclipse will take a noticeable amount of time to catch up.
Same thing happens on window resize.

GTK 1.2 improves this by collapsing sequential expose events into a
single event. A comment in the GTK 1.2 source says that our code is
based on XtExposeCompressMultiple, this appears to be a per-widget
option in Xt (compress_exposure field in core_class). I have no idea
which widgets use the option.

GTK 2.0 has a much more comprehensive solution to this problem, which
I believe is similar to the win32 solution; it maintains a "damage
region" and sends a single expose for the damaged region when the GUI
goes idle.

Is there an open bug on this? Has anyone investigated what's
happening? (Do the Motif widgets being used just not turn on
ExposeCompressMultiple, or does an SWT interaction break that trick?)

Havoc
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev