I just had a quick look at the second link from Elias' message and I was shocked to
be reading something about biological sensing that doesn't start by saying,
"Biological sensors can only detect something that is changing and the change rates
are generally logarithmic". Applies not only to sensing but also growth and almost 

everything you can measure is not linear. Hence gamma *curves* which are exponential.

0x111 to 0x222 RGB is not is not double the brightness unless your gamma is adjusted
correctly. As nice as it is, my Dell 24" IPS 4k display has terrible adjustments and
I can never get its color gamut to even near *any* other display. Well, thus the ease
with which this sort of problem emerges especially when using quick and dirty math
to improve performance. Which also suggests that it's very hard to judge whether the
algorithm is correct if the display isn't.

If it's rendering it and then reprocessing it that means it will be twice as fast
when the doubled work is eliminated, that might account for the performance difference?


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 26 April 2021 17:33, Christophe Meessen <christophe@meessen.net> wrote:

> Hello,
> 

> The article referenced by Elias [1] was very instructive and gave me the
> idea to generate gray ramps with Gio to compare the result with what we

Perhaps if you change it to a fixed point format you can eliminate these rounding errors?

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, April 20th, 2021 at 19:21, Elias Naur <mail@eliasnaur.com> wrote:

> On Tue Apr 20, 2021 at 20:11, Egon Elbre wrote:
> 

> > I'm fine with removing them or keeping them.
> > 

Just because it's legal, doesn't make it good or wise. You can break the line after the func
keyword too, but why would you? Distinctive names are important, for readability. 


I should not be depending on the syntax highlighter to tell me whether 'true' is a variable 

or a value.

I'm sure if Rob Pike was to Go as Linus is to Linux, that half the linter rules would be
enforced in compilation long ago and almost nobody would write linters. Only a lot of 

experience trying to make sense of other people's code will teach you why certain linting 

rules exist, because the compiler will let you do it, even though it makes the code cryptic.

Testing widgets would require a simulation of user input, which probably means also creating
a macro recording to create standard interactions, and could be done with offscreen 

non-painting operations. I have mentioned before the question about whether ops and events can
be serialized, and as I understand it, they can't. This also makes testing more complicated.

Having dug quite deep into a lot of the parts mentioned below, I am entirely unsurprised that
there is so many linter errors. 


There is numerous places, for example, where the keyword 'len' is used as a variable. I don't
even understand why that compiles, but the linter sure screams about it.

This is an extension of the widget/material/layout packages that I wrote, which most notably

 I have discovered that wayland in general is a pointless thing for most users
 currently due to nvidia lack of support, and so I iterated through some
 alternative nvidia driver versions to see if the bug had to do with the driver.
 Sure enough, "NVIDIA Server Driver metapackage from nvidia-driver-450-server"
 does not have this bug \o/ w00t!

 Since anyway most of the users will be running on windows which is fine (and
 great work eliminating the dependencies for it!), now just a note for nvidia
 drivers on linux to suggest for 10 series use that driver as it has no issues
 and there is a known issue of 460 and 4k displays and windows taller than,
 not sure but I can guess it's 1080.

I have discovered that wayland in general is a pointless thing for most users
currently due to nvidia lack of support, and so I iterated through some
alternative nvidia driver versions to see if the bug had to do with the driver.

Sure enough, "NVIDIA Server Driver metapackage from nvidia-driver-450-server"
does not have this bug \o/ w00t!

Since anyway most of the users will be running on windows which is fine (and
great work eliminating the dependencies for it!), now just a note for nvidia
drivers on linux to suggest for 10 series use that driver as it has no issues
and there is a known issue of 460 and 4k displays and windows taller than,
not sure but I can guess it's 1080.

Sent with ProtonMail Secure Email.

Currently the go.mod on my project refers to this build:

gioui.org v0.0.0-20201229000053-33103593a1b4

and I have discovered that on Linux there seems to be some egl
error occurring that seems to shut down the render loop, main
trigger being to maximize the window, notably, on a 4K monitor
to near 3840x2160. It also can happen sometimes just by sizing
the window too tall, the vertical axis seems to be the trigger,
as any amount of width doesn't seem to affect it.

I tried upgrading to the latest version and it is the same.

My logs show the event is triggered and thereafter the

Some future work I have in mind entails being able to run separate processes, communicating
via pipes, and I'm wondering, as I haven't looked closely, whether Ops and Events are 

serializable, and can be reconstituted and executed? Or is there some closures in there?

I want to make a shell that composes and paints the interface, and accepts input, that
can launch processes that send their UI data and read the input from the main application.
Hopefully also embedding, ideally via pass-through, instead of paint and blit.

Sent with ProtonMail Secure Email.

It should be possible to take the pixels the other code is generating and put them
in an image op and update the window, does the other GL library have a headless
functionality? I assume the game environment captures events of interest also to
the proposed Gio GUI you want to frame/overlay on it.

If you can avoid the two things drawing into the same box there might be some way to
make the box for the GL paint directly as it normally does and Gio just render nothing
in the same place. There might be synchronisation issues with this also, but it probably
would only make some screen garbage/flicker etc. idk. just thinking out loud.

I have done a little work with headless rendering. I was initially going to go for a
more traditional offscreen private bitmap, using the headless context, to make a scrolling view,
but found I was able to skirt around doing so much blitting by running the widgets to
generate dimensions, as with dimensions computing how to render the view. That's how my scrollbar