write_pixels color format
Opened this issue · 8 comments
Issue by crondog
Monday Mar 28, 2016 at 04:44 GMT
Originally opened as Cloudef/wlc#142
So after doing Cloudef/wlc#141 I have noticed that the border color which is being drawn by sway is rendered incorrectly. Sway is sending the colors in rgba format for everything however only the borders are drawn incorrectly. For some reason write_pixels is using bgra even though GL_RGBA is used. When I change format_map to GL_BGRA_EXT it works but doesn't seem right. I am out of ideas on how to fix it properly. I am still quite bad at opengl. Any ideas?
Comment by Cloudef
Monday Mar 28, 2016 at 09:48 GMT
The reason is that the pixels are written as uint32 per pixel, so in little endian it's reversed.
Comment by crondog
Monday Mar 28, 2016 at 10:07 GMT
If that is the case then why are there no problems when using swaybar. They both use the same code https://github.com/SirCmpwn/sway/blob/master/wayland/cairo.c#L3 https://github.com/SirCmpwn/sway/blob/window-borders/sway/render.c#L8
Comment by Cloudef
Monday Mar 28, 2016 at 10:12 GMT
But does swaybar render directly inside wlc? AFAIK It's separate process and doesn't probably even draw using opengl?
Comment by crondog
Monday Mar 28, 2016 at 10:27 GMT
Ah no it doesn't. Ok ill try and sort something out
Comment by mikkeloscar
Tuesday Mar 29, 2016 at 11:10 GMT
This does not work: swaywm/sway@7dc335b#commitcomment-16679816
I get:
[main.c:39] [wlc] gles2: function write_pixels at line 808: glTexSubImage2D(0x0DE1, 0, g.origin.x, g.origin.y, g.size.w, g.size.h, format_map[format].format, format_map[format].type, data) == GL_INVALID_OPERATION
So I assume GL_UNSIGNED_INT
is not supported.
It seems like all the cairo formats are native endian, so I'm not sure how to do it without depending on endianness at some point in the conversion, unless gles supports it some other way than above.
Comment by Cloudef
Tuesday Mar 29, 2016 at 11:40 GMT
You could look at cairo's gl implementation, but what I looked the things they do are not pretty :)
Comment by SirCmpwn
Tuesday Mar 29, 2016 at 13:13 GMT
I was operating under the assumption that it'd be okay to use the wrong endianness and just fix it by writing the wrong endianness in sway and looking the other way.