~vsariola


#39 key.Event does not fire for symbol keys on windows a month ago

Comment by ~vsariola on ~eliasnaur/gio

Just to confirm: is it cool to add stuff just for Windows? I'd want to e.g. add Insert key and make numpad work: it's completely silent for me NumLock on. Can I just pick some reasonable names for them?

#193 Changing window title (feature proposal) 2 months ago

Comment by ~vsariola on ~eliasnaur/gio

looks like ~inkeliz beat me to it, I'll be happy to test this is action as soon as I have been able to update my project to the latest version of Gio

#192 Issues with the new NRGBA values 2 months ago

Comment by ~vsariola on ~eliasnaur/gio

First of all, do not change the color system just because what I was trying to do originally, as I will be able to overcome this by using a combination of the tricks listed here: absolute A = 255 colors whenever possible; just applying the highlights to background colors manually etc.

But carefully doing the math I am coming to the conclusion that actually I would prefer additive blending directly in sRGB, without any gamma correction. So, neither NRGBA or RGBA are optimal for this, because they both have gamma correction. The old RGBA had the advantage that I could apply very subtle (e.g. R = 10) highlight to black with A set to 0 (purely additive blending). But, because of the gamma correction, this highlight would not actually be visible on medium gray at all, so it's not what I would want.

For what I was originally trying to do (highlighting), the best blending would be additive blending directly in the sRGB, with no gamma correction whatsoever. This would make the highlights to be always ~ equally perceptible. For example: applying a subtle highlight of 10 units, black R = 0 would become R = 10 and medium gray R = 128 would become R = 138; these being the pixel sRGB values on screen. This would always make the highlight perceptible (as long as R <= 245; larger values would start to saturate). Hue shifts are a non-issue, as the GUI is mostly gray anyway.

The original RGBA would allow to do this, by setting A = 0, IF the gamma correction was dropped altogether. But dropping gamma permanently is definitely going to backfire, as soon as someone tries blending multicolor bitmaps etc. And adding BlendOp or GammaOp sound like overkill just for this & would add further complexity to Gio, which might not be just worth it. So, I'm not sure what to make of all this, except I am shocked to find myself arguing for NOT doing gamma correction for the first time in my life :)

#192 Issues with the new NRGBA values 2 months ago

Comment by ~vsariola on ~eliasnaur/gio

I still quite don't see where the original 13 or the 12.92 in Elias' reply comes from... Following Elias' original post, the last conversion is from pre-multiplied linear 1/255 to NRBGA, which to my understanding should be (1/255)**(1/2.2) * 255 = 20.54 ~= 21. This is (close) to Egon's 20.4. Although if Gio would actually output 21, that would be even worse for me though, if 13 is already bright for my taste :)

Also, I don't quite see how "palettes" can be used in a generalized way, because I am applying highlights on stuff like pictures, icons and text etc., so the highlight needs be some kind of blending operation. It gets very complicated for me if every icon needs to know if the icon is being highlighted.

I'm surprised that there are performance issues - I would've guessed GPU handles all the blending and they have come a long way, even on mobile. Is standardizing all painting to linear float32 color too expensive (e.g. for mobiles)?

I read the what-every-coder-should-know-about-gamma article - the examples put forward are persuasive & I already knew weird stuff happens to pictures and gradients if blending is done without taking gamma into account. But in my use case (highlighting), blending without taking gamma into account could actually be the desired behavior - I don't care about color accuracy, but that there is always a perceptible difference between two colors.

All in all, I will probably manage with the new NRGBAs, by using a selective combination of the solutions proposed here (absolute colors instead of blended colors, accepting the low granularity and choosing colors around that etc.) Just takes me longer time to refactor than changing some color values.

#193 Changing window title (feature proposal) 2 months ago

Ticket created by ~vsariola on ~eliasnaur/gio

It would be great to be able to change the window title dynamically, not only during creation. I'm working on an editor app, and at least on Windows, the typical behavior is to display the path to currently open file in the title.

#192 Issues with the new NRGBA values 2 months ago

Comment by ~vsariola on ~eliasnaur/gio

For a single overlay, I can of course e.g. set higher alpha, even 255, and just give the exact value I want. But with multiple overlays or overlaying on gray, I would want the color to always be towards brighter i.e. towards white, so my understanding is that R,G,B should be 255,255,255 for this to work correctly.

#192 Issues with the new NRGBA values 2 months ago

Comment by ~vsariola on ~eliasnaur/gio

(removed double post, sourcehut is going old school on me for clicking submit twice)

#192 Issues with the new NRGBA values 2 months ago

Comment by ~vsariola on ~eliasnaur/gio

I find these gammas always confusing :) So apologies if I'm not grasping all the issues. But if there's final ^1/2.2, why isn't there initial ^2.2 when going from NRGBA to pre-multiplied linear? Would the last system for storing color proposed in http://ssp.impulsetrain.com/gamma-premult.html solve this problem?

Anyways, I'm doing material.io style dark theme overlays, and there often the recommendation is to apply e.g. a 5% white overlay, but I find it hard to apply these translucent overlays with the new NRGBA system because even alpha = 1 white is so bright, so I don't have the granularity to apply the amount of color I'd want.

#192 Issues with the new NRGBA values 2 months ago

Comment by ~vsariola on ~eliasnaur/gio

Sure. Here goes:

package main

import (
	"image"
	"image/color"
	"os"

	"gioui.org/app"
	"gioui.org/io/system"
	"gioui.org/layout"
	"gioui.org/op"
	"gioui.org/op/clip"
	"gioui.org/op/paint"
	"gioui.org/unit"
)

var black = color.NRGBA{R: 0, G: 0, B: 0, A: 255}
var translucent = color.NRGBA{R: 255, G: 255, B: 255, A: 1}

func main() {
	go func() {
		w := app.NewWindow(
			app.Size(unit.Dp(800), unit.Dp(600)),
		)
		var ops op.Ops
		for {
			select {
			case e := <-w.Events():
				switch e := e.(type) {
				case system.DestroyEvent:
					os.Exit(0)
				case system.FrameEvent:
					gtx := layout.NewContext(&ops, e)
					paint.FillShape(gtx.Ops, black, clip.Rect(image.Rect(0, 0, gtx.Constraints.Max.X, gtx.Constraints.Max.Y)).Op())
					paint.FillShape(gtx.Ops, translucent, clip.Rect(image.Rect(0, 0, gtx.Constraints.Max.X/2, gtx.Constraints.Max.Y)).Op())
					e.Frame(gtx.Ops)
				}
			}
		}
	}()
	app.Main()
}

And the results I get: https://ibb.co/10dFb23

The left side is R: 13, B: 13, G: 13

#192 Issues with the new NRGBA values 2 months ago

Ticket created by ~vsariola on ~eliasnaur/gio

I'm getting too bright colors with the new NRGBA API on windows. For example, white with only Alpha = 1 (i.e color.NRGBA{R: 255, G: 255, B: 255, A: 1}) painted on full black, gives me R = 13, G = 13, B = 13. I check this by taking a screen capture and using painting software color picker. That's way too bright.

Is this some kind of gamma correction going bonkers? How to change that?