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/ _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep