Re: Scintilla GTK 4 port

Sergey Bugaev:

> I'm writing to announce that I have developed a mostly working port of
> Scintilla to the GTK 4 toolkit.
…
> 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


I'm a bit confused here. Are you also using the 'xuges' identity responsible for https://github.com/xuges/scintilla or are these separate or related projects?

> … But there are some considerations for applications
> & widgets as well: in particular Scintilla tries to round extents to
> physical pixels via a PixelDivisions value, which is, for one thing,
> an integer, with no way to represent a fractional scale like 2.5 or
> 1.75.

   The PixelDivisions value is mostly for macOS or similar systems where windowing-layer coordinates may not match physical pixels but are always an integral number of physical pixels.

   Win32 provides fractional scaling by allowing the application/thread/window to enrol as High DPI aware with windowing-layer coordinates then matching physical pixels. The drawing-layer calls may then use scaling if they want. Other behaviour like invalidation is also directed to the windowing-layer and do not use scaled coordinates.

> Another issue here is that Scintilla paints the background behind each
> piece of text individually as its own little rectangle; this for one
> thing has the downside of producing a lot of render nodes (a lot of
> small white rectangles, instead of one large white rectangle covering
> the whole widget area), and therefore a bunch of extra work for the
> GPU to push through.

   Each text span (commonly associated with a lexeme) may have a different background colour to other spans. Other features (like highlighting breakpoint lines) may also impose a background colour. One common technique is to colour the background of major zones of the file differently: for HTML, text and tags may have one background but client-side and server-side scripts use different background colours.

   Commonly, a view may have 80 lines and less than 10 spans per line, resulting in 800 pieces of text and 800 simple coloured rectangles. GPUs can normally draw many million rectangles per second so it's unlikely that 800 rectangles will be a major problem. Looking at profiles shows that its drawing text that is slow, not backgrounds.

   A few years back, I thought this may be a worthwhile area to optimize so wrote some code that coalesced adjacent background rectangles and only drew when the background changed. While this would often reduce the number of background drawing calls to one per line, it had no effect on speed for Direct2D (Win32) or macOS. It's likely the system is batching rectangle drawing or even coalescing itself. If this produces a noticeable benefit on some platform, then it can be added, probably as an option.

> But also visually, while with integer scaling the
> sides of the rectangles align perfectly and the whole background ends
> up painted white, with fractional scaling the sides do not always
> align, and there are visible "seams". This is a general issue with
> fractional scaling, but it's aggravated by what Scintilla is doing
> (drawing these little rectangles and expecting them to align),

   Drawing lines separately has been a performance and stability win in the past. Unfortunately, seams appear even when the entire background is painted a base background colour since file zones that use a different background colour will then part draw from both the current and previous line onto that background. There could be coalescing between lines but that won't work as well where 'eolfilled' is off. The selection also commonly covers multiple lines and is the focus of attention, so the appearance of seams is noticeable. An expensive option would be to produce a list of regions from the set of backgrounds possible but that may not be as stable when interactions move a feature such as a debugger current instruction line.

   A potential addition here is for an optional base fill colour to be used as the background. Following drawing of text backgrounds can then assume that has already been drawn and refrain from redrawing with the same colour. This may reduce seaming, particularly for applications that have a consistent or mostly consistent background colour.

> There is some work on the GTK side [4] to enable opt-in *snapping* of
> render nodes to physical pixels, ...

   Strict geometric scaling that does not respect the pixel grain is often disliked, sometimes intensely. Thin lines and thin-lined boxes are particularly noticeable when they are smeared over multiple pixels.

> I had used various tricks to somewhat reconcile Scintilla code's idea
> of each platform having a single global style with this GTK's idea of
> style inherently coming from a style sheet and differing per-widget
> and with time.

   Applications and individual users often want detailed control over styling issues and it's unlikely they will write GTK style sheets when they want documentation comments to be a slightly bluer tone.

> Yet another topic is phases. In GTK, "every frame is perfect". We
> don't draw bad frames, because... why would we do such a thing? But
> Scintilla sometimes decides to just *adandon painting* if it discovers
> it needs to re-style or update something in the middle of painting.

   Some Scintilla features, like syntax styling and word-wrapping are quite slow so are performed as background activities and may slip against input to avoid blocking.

   Requiring that the entire document be fully prepared before painting will not be viable for huge documents. As well as syntax styling and word-wrapping, applications may also choose various features like spelling and linting that will require time.

> GObject introspection [6] is a cool feature of the GObject type system, where:

   In the past I have had great hopes for language interoperability systems and they never achieved all that much. Microsoft's COM is the biggest success in this space but has still underachieved with users. I was 'the COM guy' at one company and have been through all the stages of belief and disappointment here.

> There are some bits of this in the GTK 2/3 port already, but for the
> GTK 4 port, I went all in.

   This isn't a bad feature, especially if you can use it well yourself but don't expect it to be embraced by many.

   A scripting language tightly integrated into an application with an object model customized to the language is much more likely to attract users than a generic, automatically translated, API.

> It would also be great if distributions (like Debian etc) packaged
> Scintilla as a normal library, much like GTK or any other, with the
> compiled library appearing in /lib/libscintilla.so (or such), the
> headers at /usr/include/ScintillaView.h, and so on. To that end, we
> might want to write and install a pkg-config file for Scintilla; this
> would enable others to link to the system build of Scintilla easily,
> e.g. with just `dependency("scintilla")` in Meson.

   One hassle here is that Scintilla can be built with different GUI toolkits like Qt, Tk, and wxWidgets. If it's going to be installed into a global shared object directory then it may need a toolkit dongle on the name.

> Included with the port is a little application called Scintilla Demo,
> which is a very basic text editor, with tabs and menus and a
> ScintillaView in each tab.

   Unfortunately, I couldn't make this build with a bunch of 'incompatible pointer type' errors. This is on Ubuntu 25.10.

   For anyone else wanting to experiment, the prerequisites I needed (over standard Scintilla) to 'apt install' were libgtk-4-dev, gobject-introspection, valac, and blueprint-compiler.

> Speaking of SciTE, is there interest in porting that to GTK 4 (while
> simultaneously making it a lot more idiomatic)?

   I'd like to retain GTK3 and even GTK2 support so this would probably be a fork, which is fine.

> I'm looking for feedback from Scintilla core developers. Do you want
> this to go upstream?

   Eventually. It will depend on the degree of compatibility and whether it will be a support burden.

> Could we host the HTML documentation autogenerated using gi-docgen
> somewhere on scintilla.org? Is there a CI process?

   There is no CI easily available on SourceForge. If the documentation is easy to generate then it can go on scintilla.org <http://scintilla.org/>.

> Would you be open to changing those little things about Scintilla core
> that would make the GTK 4 so much less hacky? (One example of this
> might be, not querying a "platform color" globally, but in relation to
> a specific instance of Scintilla.)

   Scintilla has little global state. The Platform:: calls for colour and font are last-resort and effectively never used since these are determined by the application.

   Neil

-- 
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/5F40B0E0-9ECC-4DEC-B273-94BFB443FEED%40me.com.