Re: Scintilla GTK 4 port

On Thu, Nov 13, 2025 at 1:24 PM Colomban Wendling
<[email protected]> wrote:
> Hello Sergey,

Hello,

> Thanks a lot for this effort, it sounds very promising!  It also sounds
> like a lot of work, and trying to make it fit the GTK drawing model is a
> great news.

yay! Thanks for taking interest :)

> Kudos also for also trying to make it a more GTK-like widget, which can
> make Scintilla more welcoming for GTK developers.  Just in case it might
> be of interest, to you know of GtkSicntilla[1]?  It's quite old now, but
> it was an attempt at "GObjectizing" the API.
>
> [1] https://github.com/codebrainz/GtkScintilla

I have not seen it, thanks. It does seem interesting, but indeed old,
before many of the modern GTK/GObject development best practices were
established. I'll be certainly keeping an eye on how they did things
for future work.

> Le 06/11/2025 à 10:31, Sergey Bugaev a écrit :
> > […]
> >
> > Another issue here is that Scintilla paints the background behind each
> > piece of text individually as its own little rectangle; […]
>
> Could these rander nodes be "compressed" on the widget's side?  It might
> be some work, but usually background is fairly uniform (but for a few
> specific pieces, like selection or specific ranges), so it might be
> worth trying to background nodes that share the same properties as a
> large drawing (or just paint the whole background with the most
> prominent value), and only keep specific nodes when that doesn't match.
> I don't know how hard/CPU intensive that would be, but it might help a
> bit, wouldn't it?

I don't think the CPU complexity is going to be an issue with this;
but it would require a bunch of effort to track & match these
rectangles. Part of the complication would be that if we were to delay
rendering the background, we would have to have a robust way of
painting things out of order. We don't get information from the
Scintilla core whether the rectangle being painted is a part of the
background or not. We get requests like "paint this rectangle this
color"; it could be background (so it has to be painted below
everything else, and at the very end, so we could possibly collapse it
with neighbouring nodes) or foreground or something else, and we're
not told which one.

> Of course that wouldn't necessarily solve everything, but it might be a
> first step.  And if then nodes could be snapped to pixels, that could
> fix the rendering issues of those specific areas -- without requiring
> more complex merge logic in the widget's side.
>
> > […] I don't quite understand what is supposed to happen in
> > this case on other platforms (a brief flash of black? a bunch of stale
> > pixels from a previous frame?),
>
> IIUC, while it depends on the platform, the idea is not to flip the
> double-buffer, and so leave the previous frame untouched.  Of course,
> depending on the implementation or the use of a double-buffer at all,
> this could indeed lead to a partially refreshed frame with stale
> portions, or an entirely blank frame -- the last being most problematic.

It would be problematic even if it does retain stale pixels,
especially if the widget is being resized (so its size doesn't match
what it was when it was painted), or if it's the very first frame and
there are no previous contents etc.

This is how the infamous flickering-when-resizing happens.

> Thanks a lot for considering implementing a11y in this port!

Of course! Accessibility is very important :)

> > ## Where Do We Go From Here?
> >
> > I'm looking for people who are interested in Scintilla and GTK 4; if
> > you are, please let me know! This port could use some more testing,
> > and real-world usage beyond my own use cases. There is also still a
> > lot to work on (accessibility, IME support, call tips,
> > autocomplete...), let's hack on this together!
>
> I am, and I guess the Geany community at large is :)  I however probably
> won't have time to properly dive in this just yet, but I'd be very
> curious to look at it whenever I get some time.  I might also be able to
> help more quickly on e.g. a11y -- not making promises.
>
> Is there some code we can look at somewhere?

Great! I've uploaded a snapshot of the port, rebased on top of the
latest changes from Mercurial (so, the 5.5.8 release), to
https://github.com/bugaevc/scintilla on GitHub. Please take a look,
try building it, let me know how it goes :)

> Also porting Geany to GTK4 won't be trivial even when Scintilla is
> entirely working, so it likely won't happen quickly, but giving it a try
> might be a interesting and educational, given it's a fairly
> comprehensive user (well, we don't use each and every feature, but still).

I imagine it will be a separate bunch of work for Geany itself, yeah.

> While I hope support would be upstreamed, yes, I would be interested
> either way.  Hopefully, and especially if you don't touch anything
> outside the platform layer itself, it would be easy to combine latest
> Scintilla with your platform layer even if they live separately.

I intentionally did not, and it is very easy, yes.

> Regards,
> Colomban

Sergey

-- 
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/scintilla-interest/CAN9u%3DHf_TgDLpzuGJAyB%3DZYWW1cHeVCEbLCUN3b-ZVeX2u%3Dn0A%40mail.gmail.com.