On Tue, 10 Mar 2015 01:25:03 +0000, karl wrote:

> Please don't use SDL2 and such as basis

what is wrong with SDL2? it doesn't use `glReadPixels()`, afair. and if it's doing something very wrong, and you know how to made it better, would you please fill bugreport?

On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote:
> Also, GL should be optional, just like with Qt; it introduces noticeable lag of 16 to 48ms while being a resource hog unnecessary for most apps. I could help with implementing the abstraction layer and create a software blitter (I was professionally doing such stuff before, for GUI toolkits and stuff; but then again this stuff is trivial).

16 ms is not noticeable lag for any reasonable application.

One has to limit the design to something that can be completed in reasonable time and that offers something that existing solutions do not. So there is a need to fix the minimum requirements and target that. Either the minimum is a regular screen buffer or it is capable shader based hardware.

On Tue, 10 Mar 2015 10:32:09 +0000, Ola Fosheim Grøstad wrote:

> On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote:
>> Also, GL should be optional, just like with Qt; it introduces noticeable lag of 16 to 48ms while being a resource hog unnecessary for most apps. I could help with implementing the abstraction layer and create a software blitter (I was professionally doing such stuff before, for GUI toolkits and stuff; but then again this stuff is trivial).
> 
> 16 ms is not noticeable lag for any reasonable application.

besides, i can hardly imagine where that comes from, as videogames seems to be able to push hundreds of frames per second. it seems that "16 ms lag" here comes from "synchronise screen updates with vblank" (1000/16 ~= 60, which is common refresh rate for LCDs). and this synchronisation is purely optional on most hardware.

besides, why anyone may want to update the screen faster than monitor redraws it?

SDL2: Chooses the deprecated color-mode in GLX; prevents you from creating a core context; keeps the baseline as if everyone has only hardware from 2001 or earlier that somehow still works; while preventing batching at every single operation. glBegin, glRectf, glReadPixels+manually_flip_y+convert(). It's not the thing you want for rendering 16k+ glyphs and items onscreen in a GUI.

16-48ms : drag/resize something in an existing GL GUI. Or even better, disable your mouse hw accel (it's an overlay thing, right before the RAMDAC) (but still GL-accelerated by your compositor of choice). You'll see what I mean. Also, latency != rate.

On Tue, 10 Mar 2015 20:01:01 +0000, karl wrote:

> SDL2: Chooses the deprecated color-mode in GLX; prevents you from creating a core context; keeps the baseline as if everyone has only hardware from 2001 or earlier that somehow still works; while preventing batching at every single operation. glBegin, glRectf, glReadPixels+manually_flip_y+convert(). It's not the thing you want for rendering 16k+ glyphs and items onscreen in a GUI.

somehow it works for me.

> 16-48ms : drag/resize something in an existing GL GUI.

no prob. no noticable lag too. stunning rock-solid 85 FPS, including active game scene on the background. if i'm doing something wrong in my code, then ok, i can live with it as long as it works.

> by your compositor

ah, i just found your problem! i have no any stinkin' "compositor" on my box.

Good for you then. Sucks to be _everyone_ else using this planned toolkit which is riding on the GL-is-vital-for GUI hypetrain, eh?

On Tue, 10 Mar 2015 20:24:03 +0000, karl wrote:

> Good for you then. Sucks to be _everyone_ else using this planned toolkit which is riding on the GL-is-vital-for GUI hypetrain, eh?

never had *any* problems with GL toolkits.

ah, well, there was a 20 minutes when i had problems: when i decided to jump on that "desktop with compositor" train. and then i dropped it for good.

On Tuesday, 10 March 2015 at 20:24:04 UTC, karl wrote:
> Good for you then. Sucks to be _everyone_ else using this planned toolkit which is riding on the GL-is-vital-for GUI hypetrain, eh?

Google just dropped X11 from ChromeOS and replaced it with EGL/OpenGL.

http://www.phoronix.com/scan.php?page=news_item&px=Chrome-OS-Freon-Graphics

On Tuesday, 10 March 2015 at 21:17:02 UTC, Paulo Pinto wrote:
> On Tuesday, 10 March 2015 at 20:24:04 UTC, karl wrote:
>> Good for you then. Sucks to be _everyone_ else using this planned toolkit which is riding on the GL-is-vital-for GUI hypetrain, eh?
>
> Google just dropped X11 from ChromeOS and replaced it with EGL/OpenGL.
>
> http://www.phoronix.com/scan.php?page=news_item&px=Chrome-OS-Freon-Graphics

It says KMS/DRM and OpenGL for 3D, though. Probably because of battery life?

On Tuesday, 10 March 2015 at 20:24:04 UTC, karl wrote:
> Good for you then. Sucks to be _everyone_ else using this planned toolkit which is riding on the GL-is-vital-for GUI hypetrain, eh?

You are the one that suggested distance fields ;-)... Which
actually is what I want to, but not only for fonts. :]