Far future color thoughts #3216
Replies: 2 comments 2 replies
-
|
Talking about vectorization actually just gave me a tangentially-related thought... Some of the code that deals with text can potentially benefit from vectorization for a massive performance benefit. That is simplest to apply in three scenarios I can think of, for the data:
Some other things, such as equality comparisons on certain types, especially if they have to compare several fields/properties, can also be vectorized for potential gains. It's wild how quickly vectorized wide-instruction stuff overtakes its narrow-instruction counterparts. And modern .net has made use of it soooo much simpler than it used to be. |
Beta Was this translation helpful? Give feedback.
-
|
Given colors are assigned per character of the console, any <s>Transparency</s> Alpha
effect is likely to look a bit janky.
We have had a long standing need for Transparency though. E.g. to draw
popup over small area of console.
…On Sat, 27 Jan 2024, 09:09 dodexahedron, ***@***.***> wrote:
Talking about vectorization actually just gave me a tangentially-related
thought...
Some of the code that deals with text can potentially benefit from
vectorization for a massive performance benefit.
That is simplest to apply in three scenarios I can think of, for the data:
- If the data is chars, and the operations being applied are
representable as mathematical operations, it can be operated on as vectors
of shorts (char is not supported).
- If the data is encoded as UTF8, it can be vectorized as integers
(since UTF8 can result in up to 4 bytes).
- If the data is known to be ASCII or otherwise known to only consist
of single-byte characters, it can be vectorized as bytes.
- This can even be controlled by a mechanism as simple and naive as
a global flag that gets set the first time a wide character is encountered,
after which it's just assumed stuff is wider. Could be per-view, as well,
to make that a little more forgiving.
Some other things, such as equality comparisons on certain types,
especially if they have to compare several fields/properties, can also be
vectorized for potential gains.
It's wild how quickly vectorized wide-instruction stuff overtakes its
narrow-instruction counterparts. And modern .net has made use of it soooo
much simpler than it used to be.
—
Reply to this email directly, view it on GitHub
<#3216 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHO3C5DB2J5YBBVUWE5D7Z3YQS755AVCNFSM6AAAAABCM5T642VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DENRUGE3DE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Ha yeah I figured it was going to be more focused like that. I think, TBH, that it's actually a net good thing, in terms of how difficult it would be to use when we get to that point. |
Beta Was this translation helpful? Give feedback.
-
|
I also want to know why I just responded to that on my phone when I literally have github up on my computer right in front of me.. 🤦♂️ |
Beta Was this translation helpful? Give feedback.
-
So, as of now, and for the V2 release, Terminal.Gui, while it does use and store 32-bit color values, does not support the alpha channel.
For V2 I think that's perfectly reasonable.
However, it's a potential nice-to-have for future enhancements, and, in theory, shouldn't actually require that much additional work to implement, for terminals that support more than 16 colors.
There are some libraries out there that do all the hard work around things like color blending (which is a bunch of math and very unintuitive if you've never done it before - especially with alpha involved). One that I've used before that is pretty popular and has some excellent features as well as a strong performance focus (including vectorized hardware instruction use for the math), is https://github.com/koszeggy/KGySoft.Drawing
It does not use a standard license, but its license is MIT-compatible. It's not all that dissimilar from the MIT license, at the end of the day, and has explicitly zero restrictions for use of it in library form. For use in source form it just requires attribution and, if alterations are made, notation of those changes. So, pretty much MIT.
Some of their code around SRGB colorspace blending (which is what we'd be doing) is not all that dissimilar from some code I had written for another project, though it does do the entire thing in SIMD-land, which is cool. That particular code looks like it has some pretty significant simplifications and some small improvements that can be made pretty trivially, if we were to use it, since their is the way it is for backaward compatibility with much older .net and .net framework versions. Some of it can be reduced to just a couple of method calls on Vector128s (which are SSE2, 3, and 4 instructions on x86_64 hardware and similar stuff on ARM64 hardware, and fall back to standard floating point math on stuff without those instructions).
The majority of any work we'd have to do, to support alpha, is just that we would actually have to composite colors of elements drawn over others, rather than just taking whatever the last element's color is and using it unconditionally. Instead, what you'd do is, whenever something is drawn, take the current color of the underlying element and blend it with the color specified for the new element, and then use that when drawing. If the new one is full-opaque, you can short-circuit it and just use its color, which would be what happens in the majority of cases, exactly as it already is. In any case, that compositing work isn't that much, for most cases.
Where it CAN get hairy is dependent on just how flexible we would want to be and where alpha blending would be allowed. For example, if it is allowed for all View types and their contents, would alpha blending be respected for every pixel of overlapping Views?
Consider a window with, say, a treeview that takes up the left half of the window, and another treeview that takes up the upper half of the window, added in that order to the window. So three things to composite/blend. Does the quarter of the window covered by both have the composited color resulting from the window and both treeviews? What if there's another view of some sort on top of them, inside that quarter, right in the middle of that area? Are the pixels covered by it fully composited all the way down, too?
I'm not currently familiar with the method TG uses to set the color of each pixel, though. If it already does it one by one, then this is all pretty simple.
Also, @tig had some thoughts regarding performance he brought up in the recent issue about colors. The library I mentioned above, since it has to do a lot more work, thanks to blending, does do caching of color values resulting from compositing, so that non-trivial work doesn't have to be done repeatedly, for the same inputs.
Anyway... Just some stuff I had bouncing around in my head for later on. I was curious just how much of System.Drawing is supported on all platforms (which turns out to be quite a bit, now, actually), and that got me thinking about this.
Beta Was this translation helpful? Give feedback.
All reactions