On Wed Dec 11, 2019 at 2:59 PM ~sircmpwn wrote:

EXT_color_buffer_half_float in Lima may be possible but would be Hard. Can you get away without using float textures as render targets?

Yes, I believe so. Note that without render support (EXT_color_buffer_half_float), gio won't need float textures (OES_texture_half_float).

https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_color_buffer_half_float.txt says Requires OpenGL ES 2.0., and AFAIK GLES 3.0 has both floating point targets and FP FBOs in core. What did I miss?

Thanks, I re-added the GLEXTcolorbufferhalf_float check (spelled correctly this time) in 4a628d1c2c2c268ef896a25ce9c742817c6d706e.

What do you mean by GLES 3.0 or newer? https://www.khronos.org/registry/OpenGL/extensions/OES/OES_texture_float.txt lists the LUMINANCE/HALFFLOATOES combination.

According to my reading of GLOEStexturehalffloat, the single channel GLLUMINANCE is supported with HALFFLOAT_OES. The commit https://git.sr.ht/~eliasnaur/gio/commit/8a44ac11d8379ccb4214e5daaf113194fa95c1f3 implements that, keeping the 4-channel fallback.

Does that work on Lima, and in particular fixes the everything will be 2x slower with FP16 textures compared to RGBA8888. warning? If so, the first two FBO workarounds from above are not required, leaving only the caching optimization.

On Wed Dec 11, 2019 at 3:42 AM ~sircmpwn wrote:

The Lima developers have asked me to pass along this warning: everything will be 2x slower with FP16 textures compared to RGBA8888.

If it makes any difference, gio only needs one channel of FP16.

The ideal format is a single-channel (GL_RED) half-float target. Having a four-channel FP16 texture is indeed a waste in memory and (depending on how Lima does FP16) processing. Worse, the 4-channel fallback is only needed on slower GPUs where both resources are scarce.

So gio could do a combination of the following to work around the FP FBO issue:

• When forced to use a 4-channel RGBA FP16 format, use all 4 channels and a quarter of the texture dimensions.
• Not use RGBA FP16 formats at all and instead convert the single channel floating point to and from 4-channel RGBA bytes in the shaders. Perhaps that's what the Lima developers are doing, but with a (slower) R16G16B16 format?
• Cache the outline renders across frames. Text shape rendering is by far the most expensive to draw even with perfect FBO support, and the shapes rarely change.

I'm pretty sure #3 is going to happen regardless of this issue. Doing the other 3 depends on sRGB, see below.

Managed to get past these issues, now dealing with sRGB support. Still knee deep in driver land. gio should consider a more conservative approach to OpenGL if you hope to have good mobile support...

I don't see how gio can get around not having at least sRGB texture support (an sRGB framebuffer is optional but saves a window sized copy per frame) without either (1) ditching sRGB altogether or (2) accept different rendering output depending on device.

So in conclusion, if you can get sRGB support on the Lima, I'm happy to attempt the FP FBO workarounds above. Otherwise, I'm not convinced it's worth the trouble.

On Tue Dec 10, 2019 at 11:02 PM ~sircmpwn wrote:

Yeah, Lima can support OES_texture_half_float with a patch, in theory, but not OES_texture_float.

Great, that should work fine with Gio.

On Tue Dec 10, 2019 at 10:21 PM ~sircmpwn wrote:

Working on a driver patch.

Nice.

I can get you mediump (half float) on the Lima driver, if you're able to ditch highp and meet me in the middle we'll be in business.

Can you elaborate? Gio is fine with HALFFLOAT(OES) FBOs if that's what you mean. Are you saying the Lima driver somehow restricts the shader precision to mediump when outputting to a half float fbo? AFAIU, the shader precision is unrelated to the output format (how else would a shader output to, say, an RGBA UNSIGNED_BYTE FBO?

CC=Greg Pomerantz gmp.gio@wow.st

On Tue Nov 26, 2019 at 4:35 PM ~adamseraj wrote:

Will there be interest in the issue of connecting the Gio app to the devices? Such as camera, microphone, wafi, Bluetooth ... I think this will have a strong impact on Gio's success and rapid spread. At least provide an easy way to help connect with mobile devices and desktops.

Yes, that's very much a wanted feature. CC'ing Greg who has been working on getting Bluetooth devices working with Gio programs.

Another question : I did not find some commands in the Gio tool. Like: gio build --target android... ??? Thank you so much

Where did you see the reference to gio? There is the gioui.org/cmd/gogio command, renamed from gio because there is already a command named gio on most linux systems.

$ go get gioui.org/cmd/gogio
$ gogio -target android ...

On Sun Nov 24, 2019 at 11:34 AM Alessandro Arzilli wrote:

On Fri, Nov 22, 2019 at 01:46:51PM -0000, ~eliasnaur wrote:

On Fri Nov 22, 2019 at 6:24 AM Alessandro Arzilli wrote:

I believe I have already disabled sub-pixel AA, and there is no way to (that I can find) to convince ftview to disable stem darkening.

At: https://github.com/aarzilli/blah/blob/master/tqbfjotld2.png you can see on the third line the effect of gamma 2.2, which is still darker than gio.

Indeed. Another reason for the lighter text is that package opentype does very basic hinting (rounding the advance to the nearest pixel):

https://github.com/golang/image/blob/e7c1f5e7dbb87d8921928a6d9fc52fb31ce73b24/font/sfnt/sfnt.go#L1527

For example, will rounding to nearest pixel will always result in the letter stems be pixel aligned? I don't know (yet).

Have you reported this to pkg.go.dev? I don't think there's anything to do on Gio's side.