Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[Akira Kyle <akira@akirakyle.com>]

On Mon, Nov 30, 2020 at 08:39 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

>> > Anyway, this just tells me that GTK is not a good starting 
>> > point
>> > for embedding widgets.  Do other projects build embedded 
>> > widgets
>> > on such shaky grounds?
>> 
>> I wouldn't say GTK isn't good for embedding widgets. In fact 
>> I'd 
>> say it's probably great if you're wanting to extend an existing 
>> GTK app with custom widgets. The problem is Emacs, despite 
>> using 
>> GTK as a toolkit, isn't really a GTK app.
>
> First, which of the problems you mentioned are related to Emacs 
> not
> being a GTK application?

All of them.

> And second, there's a branch in our repository where Emacs _is_ 
> made
> to be a GTK application, AFAIU.

If you're referring to Yukki Harano's feature/pgtk branch, then 
that's actually what I'm primarily targeting in my development of 
emacs-webkit since the usual Emacs compiled `--with-x` has an 
additional problem from what I've previously described. It seems 
gtk widgets (or at least the webkit widget), flicker constantly on 
`--with-x`. It seems to be related to the double buffering 
implementation since setting the frame parameter 
`(inhibit-double-buffering . t)` fixes it. I haven't had the 
motivation to debug this due to the mess of xterm.c and because I 
see pgtk as the future of Emacs on GNU/Linux systems as X becomes 
increasingly obsolete.

AFAIU the pgtk version, like the ns version it was modeled after, 
doesn't implement everything in the main frame area of Emacs as 
widgets, only the tool and menu bars are implemented as proper 
widgets. The main frame area is treated as just one big canvas 
that redisplay works its magic on as it would if it were just a 
TUI.

>> > This is solvable.  We already have similar situation in the
>> > display engine, where some display element cannot be usefully
>> > "clipped".  We either don't display it at all or display it 
>> > on the
>> > next screen line, depending on the wrap mode.
>> 
>> I don't doubt its solvable, but how satisfactorily and at what 
>> complexity?
>
> No complexity at all, it's almost trivial, because the display 
> code
> already does that.  As for "satisfactorily" part: what can be
> unsatisfactory about displaying the widget on the next screen 
> line?

That's fine, and would be the expected behavior when lines are 
supposed to wrap. But when lines are not wrapped, I would not 
expect a display element to disappear as soon as one pixel of it 
exceeds the window border.

>> What if the element is large and 99% of it could be visible? 
>> What if
>> the element is wider than the window?
>
> These are marginal cases: you are talking about very large 
> widgets
> that in addition refuse to be resized.  How many are like that? 
> And
> what else can we do with widgets that are (1) large, (2) won't 
> resize,
> and (3) cannot be clipped?
>
> The perfect should not be the enemy of the good, right?

Take the drawing canvas idea, the canvas widget would be the size 
of an image. Already I find the way redisplay doesn't like to 
display images clipped at the top of the window jarring. If I 
wanted to zoom into the widget if it was displaying something 
detailed, I wouldn't want it to suddenly disappear. I think Emacs 
needs to be able to clip the elements its displays in order to not 
end up with what I would call surprising and frustrating 
behavior. Hence my original argument that the way gtk widgets are 
currently handled is not in general, a good path forward for such 
features.

>> What if `window-resize-pixelwise` or `frame-resize-pixelwise`
>> non-nil and the element is on the last, partially clipped line?
>
> We don't display it.  How is this different from a any other 
> large
> display element that cannot be shown in the viewport?

Images are the only other large display element that I'm aware of 
and images are clipped in such cases, which is good as large 
images make their line very tall so very often they end up 
partially displayed in the last line.