[bug #17717] Use "open panel" twice make it unusable

[Richard Frith-Macdonald]

Follow-up Comment #35, bug #17717 (project gnustep):

Responding to Yen-Ju Chen's three posts in one ...

> I think the size of XWindowBuffer is never updated even with the latest
> backend.

Probably ... we need to figure out why not though.

> I don't see the +windowBufferForWindow:depthInfo: is called
> when new expose event occurs. Maybe that's the bug.

I think that +windowBufferForWindow:depthInfo: should be called whenever the
window is resized (and only when the window is resized).  The idea of making
sure that expose events were processed in the event stream passed to the GUI
was that this should mean that resize and expose events were handled in order
... so that the buffer would have been resized to the new size before we
process an expose event for the new size.

> And I realize that window->xframe does change for no reason.

Something must change it ... I will look through the code and try to identify
all places where it can be changed and add debug to log all changes.

> So the solution would be to resize the buffer for every exposure
> if the buffer is retained.

This would not be good ... it would mean that we lose buffer contents on each
exposure ... in which case we may as well not have a buffer at all since every
expose event would have to trigger a redraw of the exposed region.

Talking about decoration of windows ...
> Therefore, you probably cannot expect the window size will stay the same
> during the order out and order front. But most of time, they will.

I think you are mistaken here ... changes in decoration should not effect the
size of the window we are drawing into, just the offsets from its parent to
it.  Thus the size of the wdrawign window and the buffer area should not be
effected by any decoration changes.

However, I certainly that the area of calculation of offsets is one we need
to be very careful about, since if we pick different sets of information from
the window manager at different times  we could potentially map from X to OS
coordinates using one set of offset info, and map back again later using a
different set of info resulting iun incorrect coordinates.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?17717>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/