On Tue, 10 Mar 2015 21:17:01 +0000, Paulo Pinto wrote:

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

that's 'cause they don't need the whole power of X11. most of the tasks there are done by html rendering engine (and done badly, 'cause using HTML for GUIs sux), so they throwed X11 away. right move for such crippled OS.

Le 10/03/2015 02:25, karl a écrit :
> Please don't use SDL2 and such as basis, or OpenGL with
> glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a GL
> driver dev (userspace) for a smaller company, and I see too much gore in
> popular software like that (gnome3 is the most-horrific). A
> fully-featured GUI with GL needs only a thin wrapper for
> glXGetProcAddress, GL context creation, BitBlt-like things and
> font-glyph cache (or better yet, signed-distance-field text rendering).
> Something like this:
>
> Base (sans clipping, I haven't ported it from asm yet):
> https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw
>
> SDF text:
> https://www.mapbox.com/blog/text-signed-distance-fields/
>
> 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).
>
> A 32-bit backing-store is always vital (DDB+GDI dibsection, GL texture
> and such). Qt has it (and implemented really-well) and that's the first
> pixel-related thing we should implement. BGRA8 will be the best format
> (blue in LSB).
> A 9-cell blit will also be vital functionality.

That the way we choose with DQuick. I use SDL2 under linux only cause I was unable to set up a window with xcb. Under Windows the window is created by native win32 functions.

For glyph I use fontconfig + freetype and I generate atlases,...

I started a DirectX renderer, but it doesn't work for the moment. So pluggin a software renderer would be possible too.

DQuick is just like QtQuick, a simple render coupled to a language that support property bindings, if you want more advanced GUI components like widgets the user have to create them based on primitives (images, border images,...).

But just like Qt do, advanced components can be added after to the library as an extension (QtQuick.Controls).

A such GUI library is in theory simpler to do, cause there is no tricky things to implement in it to follow native UI of platforms,...

On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote:
> Please don't use SDL2 and such as basis, or OpenGL with glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a GL driver dev (userspace) for a smaller company, and I see too much gore in popular software like that (gnome3 is the most-horrific). A fully-featured GUI with GL needs only a thin wrapper for glXGetProcAddress, GL context creation, BitBlt-like things and font-glyph cache (or better yet, signed-distance-field text rendering). Something like this:
>
> Base (sans clipping, I haven't ported it from asm yet):
> https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw
>
> SDF text:
> https://www.mapbox.com/blog/text-signed-distance-fields/
>
> 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).
>
> A 32-bit backing-store is always vital (DDB+GDI dibsection, GL texture and such). Qt has it (and implemented really-well) and that's the first pixel-related thing we should implement. BGRA8 will be the best format (blue in LSB).
> A 9-cell blit will also be vital functionality.

@karl

Can you check the proposal of the new color module by Manu?
https://github.com/D-Programming-Language/phobos/pull/2845

Do you see any issues there?

Piotrek

I'm unsure of the "gamma" space, Adobe should be enough to cover things (the curve is practically identical). Still, they are different at 0xA7 and 0xBE, so maybe useful for some files. GPUs and every non-specialized monitor only do sRGB<->linear.
So, all's good with that pull request, just "gamma" might be useless and confusing.

Gamma is a common color-tweaking setting available in some games. Don't know why, but it's done that way.

Read-up on what sRGB and AdobeRGB is...

On Wednesday, 11 March 2015 at 08:22:30 UTC, Xavier Bigand wrote:
> DQuick is just like QtQuick, a simple render coupled to a language that support property bindings, if you want more advanced GUI components like widgets the user have to create them based on primitives (images, border images,...).
>
> But just like Qt do, advanced components can be added after to the library as an extension (QtQuick.Controls).
>
> A such GUI library is in theory simpler to do, cause there is no tricky things to implement in it to follow native UI of platforms,...

How can I take a look at DQuik? Is it in working state?

Le 13/03/2015 20:38, Aram a écrit :
> On Wednesday, 11 March 2015 at 08:22:30 UTC, Xavier Bigand wrote:
>> DQuick is just like QtQuick, a simple render coupled to a language
>> that support property bindings, if you want more advanced GUI
>> components like widgets the user have to create them based on
>> primitives (images, border images,...).
>>
>> But just like Qt do, advanced components can be added after to the
>> library as an extension (QtQuick.Controls).
>>
>> A such GUI library is in theory simpler to do, cause there is no
>> tricky things to implement in it to follow native UI of platforms,...
>
> How can I take a look at DQuik? Is it in working state?

It's on github :
https://github.com/D-Quick/DQuick

We have some tests working, but it's not enough to be usable on a real application.

The "DML engine" is almost finished. This night we worked on the file reloading. This will allow direct update of GUI when modifying lua files without loosing states.

Once the "DML engine" polished, we'll progress and the render part and event system. For the moment the mouse input aren't propagate correctly in the hierarchy,...

But we hope finding more time to work on it this year.

On 13 March 2015 at 09:54, karl via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> I'm unsure of the "gamma" space, Adobe should be enough to cover things (the
> curve is practically identical). Still, they are different at 0xA7 and 0xBE,
> so maybe useful for some files. GPUs and every non-specialized monitor only
> do sRGB<->linear.
> So, all's good with that pull request, just "gamma" might be useless and
> confusing.

'gamma' is used in many performance-oriented applications, because it's MUCH faster to calculate/convert than sRGB (which is completely mental).

Note, I still have a LOT of work to do on that module, I'm not really
happy with it. But I wanted to try that approach out.
I think I'm leaning more towards explicit types for different
high-level colour spaces after experimenting with that design. I'll
probably leave selection of colourspace detail to template arg though
(sRGB/linear/etc).