problem disabling display optimizaions

problem disabling display optimizaions

[joakim]

I disable display optimizations in the xwidget branch currently because
I need to reliably catch redisplays notion about where objects are on the
screen. The idea has always been to get back to this and re-enable
optimizations in stages.

Anyway, so the code to move the xwidgets around on screen was reliable
for a very long time. Then I spent some time on the new webkit xwidget
which had entirely different issues. 

Now, when I return to the simpler xwidgets such as buttons and sliders,
they no longer moved properly in the buffer. The cause might be changes
in redisplay or more likely some error of mine. redraw-display restores
proper placement immediately.

I can restore the previous behavior by disabling scrolling_window() by
making it return early. This function is similar to the try_* fns.

Now I would like to verify how redisplay works.

The problem happens because fill_xwidget_glyph_string doesn't get called
during redisplay any more. This works the same as the other
fill_*_glyph_string functions. If display opimizations are completely
disabled it should be called. Redisplay tries to optimize away the fill
calls by using hardware scrolling if possible. But if the screen is
scrolled that way the xwidget won't be notified that Emacs desires its
movement(yet).

GLYPH_DEBUG allows for disabling of optimizations and I have been using
that. GLYPH_DEBUG now compiles here but doesn't disable optimization as
I expect.

GLYPH_DEBUG listens to these variables:

inhibit-try-window-id
inhibit-try-window-reusing

There ought also be a inhibit-try-window but there isn't for some
reason. 

produce_xwidget_glyph gets called like the other produce_*_glyph
functions but at that time we don't know screen placement.

so, to summarize, GLYPH_DEBUG doesn't seem to inhibit optimizations as
it used to. Disabling scrolling_window() appears to be enough to get
xwidgets working again.

-- 
Joakim Verona

Re: problem disabling display optimizaions

[Eli Zaretskii]

> From: joakim@verona.se
> Date: Wed, 10 Aug 2011 16:06:00 +0200
> 
> 
> I disable display optimizations in the xwidget branch currently because
> I need to reliably catch redisplays notion about where objects are on the
> screen. The idea has always been to get back to this and re-enable
> optimizations in stages.

FWIW, I have never found myself in the need of disabling
optimizations.  They never gave me any trouble, and not because I'm
terribly smart when it comes to reasoning about what redisplay does.

Perhaps the reason is that my changes never touched anything related
to layout in general and glyph string level in particular.

> I can restore the previous behavior by disabling scrolling_window() by
> making it return early.

Then it sounds like stepping with a debugger through scrolling_window
is your best bet to find the problem.  Although what you say below
seems to point out that you already know the answer.

> This function is similar to the try_* fns.

Not really, but this isn't important for your purposes.

> Now I would like to verify how redisplay works.

Welcome to the club ;-)

> The problem happens because fill_xwidget_glyph_string doesn't get called
> during redisplay any more. This works the same as the other
> fill_*_glyph_string functions. If display opimizations are completely
> disabled it should be called. Redisplay tries to optimize away the fill
> calls by using hardware scrolling if possible. But if the screen is
> scrolled that way the xwidget won't be notified that Emacs desires its
> movement(yet).

scrolling_window exists precisely to _avoid_ recreating and redrawing
glyph strings.  If xwidget cannot tolerate that, then you will have no
choice but disable the scrolling_window optimization.  One way of
doing that would be to fiddle with row_equal_p, so that it never
returns non-zero when xwidget won't like that.  (I cannot formulate
the condition more accurately, because I have no idea what xwidget is
and how it modifies the display engine.)

However, please try to see if at least matrix rows that aren't related
to xwidget can be reused in scrolling_window.  Disabling redisplay
optimizations generally makes Emacs unusable.

Can you explain why you need to re-fill xwidget glyph strings when a
window is scrolled, in terms that could be understood by someone who
knows nothing about xwidget?

> GLYPH_DEBUG allows for disabling of optimizations and I have been using
> that. GLYPH_DEBUG now compiles here but doesn't disable optimization as
> I expect.

AFAIK, GLYPH_DEBUG disables optimizations in xdisp.c, but does not
affect update_frame and its subroutines, to which scrolling_window
belongs.

> produce_xwidget_glyph gets called like the other produce_*_glyph
> functions but at that time we don't know screen placement.

Not sure what this tries to say or how important it is for
understanding of the overall issue.  How is the screen placement
relevant?

> so, to summarize, GLYPH_DEBUG doesn't seem to inhibit optimizations as
> it used to.

Are you saying that GLYPH_DEBUG could disable scrolling_window in the
past?  If so, when was that?