Abiword does not rely on GTK to update the canvas after an editing
command. It has its own update mechanism. Most of the time, this
triggers a call to FV_View::_draw to redraw the canvas. If the canvas
needs to be redrawn because a window from a different program was
closed (and the Abiword window was below), we catch the GTK signal
(XAP_UnixFrameImpl::_fe::draw) and call FV_View::_draw.
Simon
On Fri, May 10, 2013 at 5:46 PM, Daniel Drake <dsd@laptop.org> wrote:
>
> Hi,
>
> Can anyone help me check on a quick detail?
>
> If I understand it right, abiword offers a custom GTK widget for the
> document canvas.
>
> When the user presses a key, a new character gets drawn on the canvas.
> As with any change to on-screen content, this should then trigger a
> call to gtk_widget_queue_draw() or gdk_window_invalidate_rect() or
> similar so that the X server knows that the widget contents have
> changed so that the screen can be updated.
>
> After doing some greps I can't see where that happens.
>
> There is XAP_UnixCustomWidget::queueDraw() but I don't see where this
> gets called from the "user inputted a new character" codepath.
>
>
> Background: I'm working on a bug on the OLPC laptop where abiword text
> does not appear when the display is rotated with xrandr.
>
> I thought this was a graphics driver bug so I checked all of the EXA
> rendering operations in a lot of detail. Nope, the graphics driver is
> rendering what it is being told to render.
>
> So now I would like to do a quick sanity check at the abiword layer.
>
> Daniel
Received on Sat May 11 12:56:23 2013
This archive was generated by hypermail 2.1.8 : Sat May 11 2013 - 12:56:23 CEST