On Thursday 20 June 2002 4:36 pm, John Levon wrote:
> On Thu, Jun 20, 2002 at 11:33:29AM +0100, Angus Leeming wrote:
> > BufferView and lyxfunc no longer resize() themselves. Presumably because
> > the resize event is coming from behind the frontends firewall and they
> > should be told about it, not the other way round?
>
> Right.
>
> > XScreen::expose now posts an XEvent to XSendEvent instead of copying a
> > pixmap to the window using XCopyArea.
> >
> > Ok, now could you explain how all this fits together?
> >
> > Start with:
> > 1. Resize the window using the mouse.
> > 2. This triggers an XEvent, received by ???
> > 3. This triggers an FL_DRAW event recieved by
> > XWorkArea::work_area_handler 4. This calls XWorkArea::paint
> > 5. which calls updateGeometry to generate a new pixmap and XCopyArea to
> > paint this in the window.
> >
> > So where does XScreen::expose fit in?
>
> Well, xforms doesn't seem to have an event for notifying geometry
> changes (!) so when it changes FL_DRAW is sent, and we notice it changed
> and tell the bv, which then repaints the necessary parts of the pixmap,
> and calls expose on the necessary bits. Which then sends /another/
> FL_DRAW (but in theory this shouldn't matter too much because of the
> double buffering).
I think I'm getting the hang of this. XScreen::expose sends an XEvent that is
placed on the xforms event loop and eventually triggers a call to
fl_handle_form, which in turn ends up calling the work area handler?
> There are also core-triggered repaints which once again cause the expose
> event which sends an FL_DRAW.
> Basically, we /never/ draw directly onto the window except in response
> to FL_DRAW, as it should be ...
Indeed. I think I see this now.
So that means that the code in XScreen that calls
XCopyArea (display, cursor_pixmap, owner_.getWin(), ...
direct is incorrect (which is your comment about the cursor being broken)?
Instead it should call
XCopyArea (display, cursor_pixmap, owner_.getPixmap(), ...
expose(...)
Am I on the right track?
Angus
