Rabbitholes be like loooooooooooooooooooong ones, right?
Indeed! In my case, keeping me from doing sailfish work! Oh, no!
Seems @flypig finally managed to escape from a particularly deep one. Good to hear you fixed the freezing issue!
Sheesh, was a bit of a read to catch up! And all for the difference in EGL and Egl
@flypig i suggest giving the LIB_GLDEBUG
/ MESA_DEBUG
a try. They will generate alot of output but might highlight the failing function right away. Its time for the heavy weapons
Thinking about debugging GL code, maybe @flypig, you know or already uses this:
glEnable(GL_DEBUG_OUTPUT);
glDebugMessageCallback(_openGLMessage, 0);
where you can provide a function dealing with GL errors:
static void _openGLMessage(GLenum source _U_, GLenum type, GLuint id, GLenum severity,
GLsizei length _U_, const GLchar* message,
const void* userParam _U_)
{
gboolean warn = TRUE;
const char *ctype, *cseverity;
switch (severity)
{
case GL_DEBUG_SEVERITY_LOW:
cseverity = "LOW";
break;
case GL_DEBUG_SEVERITY_MEDIUM:
cseverity = "MEDIUM";
break;
case GL_DEBUG_SEVERITY_HIGH:
cseverity = "HIGH";
break;
default:
cseverity = "UNKNOWN";
}
switch (type)
{
case GL_DEBUG_TYPE_ERROR:
ctype = "ERROR";
break;
case GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR:
ctype = "DEPRECATION";
break;
case GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR:
ctype = "UNDEFINED";
break;
case GL_DEBUG_TYPE_PORTABILITY:
ctype = "PORTABILITY";
break;
default:
ctype = "OTHER";
warn = FALSE;
}
if (warn)
g_warning("GL CALLBACK: type = %s, severity = %s, id = %d, message = %s",
ctype, cseverity, id, message);
else
g_debug("Visu OpenGL: type = %s, severity = %s, id = %d, message = %s",
ctype, cseverity, id, message);
}
I’ve used it to partly understand what was wrong in my GL code. But maybe it’s not appropriated in your case if it’s a transfer issue between GPU and offscreen buffer… Good luck anyway !
If its an opengl transfer, it will show!
@flypigg about the misalligned texture;
two things can go wrong (assuming the data is correct in the texture) :
- alignment of data (start, stride)
- format of pixel (ARGB / RGBA etc)
Which one is the texture you are looking at configured with?
Is the image the same the browser would show? Which image are you displaying in the embedded view?
Just some small ideas, hth
Thanks for the input @tortoisedoc. I know what sort of image I’m asking for (RGBA in UNSIGNED_BYTE format). But whether that’s what’s being produced is less clear. Based on the code I expected it to be in the same format as is rendered to the screen, but that doesn’t seem to be the case after all
See where the glTexImage2d is used ?
https://registry.khronos.org/OpenGL-Refpages/es3.0/html/glTexImage2D.xhtml
that should give you an idea where the data comes from, maybe
@flypig can you post one of the texture files? when i was working on my libcamera app, I found a website that let you upload a raw image, enter the width/height and try different parameters until you got it to display correctly. Right now I cant remember what it was though, but i’ll keep looking!
Basic image editors, i.e. gimp, can also open anything. I have used it succesfully in similar situations.
@flypig some more thoughts on the alignment / stride etc:
assuming the rendering logic being the same in both off-screen and on-screen;
the difference can be in the shaders used; ie the vertex format…
and Id believe the same image / website would render ok on the on-screen pipeline…
so perhaps comparing the initialization of the rendering pipelines might give some insights…no idea how easy that is on firefox tho…
@flypig looking at the shape of the texture in the forelast post;
could it be the background element of the sfos website:
Thanks all for the input (and sorry for not replying sooner; I was travelling last week).
@tortoisedoc, you’re right, and well spotted, it should definitely be something to do with the sailfishos.org site as this was the site I was attempting to render. But how it fits in to it I’m not too sure I’m afraid.
@piggz, @vige, I’ve tried running the textures through GIMP’s raw importer, but with only the results you can see in my diary entries, so not very successfully unfortunately.
If any of you have the time, I’d love it if you can get better results. This archive contains a collection of the original raw files:
https://www.flypig.co.uk/dnload/dnload/sailfishos/gecko/gecko-frames-01.zip
The originals are all, in theory, 1080 x 2520 pixels in size and either RGBA (the first set) or RGB (the second set). But this may not be what they are in practice.
I thought it might be an offset issue, but after tooling about in gimp, I’m not so sure. What ‘should’ they look like
The RGB data does seem to be RBG, the RGBA, I’m notsure. You said unsigned?
using imagemagick on the RGBA frames I get something like this using:
convert -size 1080x2520 -depth 16 -define quantum:format=usigned gray:frame050.data -auto-level result.png
Which probably needs an offset to get there but bits of sailfish logo can also be recognized. It does look unsigned judging from the results of the convert operation.
@flypig okay that’s something;
so the next piece of the puzzle: if you access sailfishos.org from the normal browser, does it render OK?
If so, it might mean the setup of the opengl context is wrong on the embedded side → comparing context setup data & capabilities between the two (browser and embedded (embedlite?)) would be the first I’d do. Only after confirming these as being identical would I jump in the brute-force deep pool as a measure of last resort
There is definitely almost an image there! For this I used PixelViewer, which allows to quickly try many different possible formats, this one is RGBA_8888
Looking at the logo on top, it is shifted 5 times . So maybe something like 5 channels in this image somehow?
The 0 on the phonescreen is only once dominant which supports the color channel theory…but 5?
I seem to recall something about a mode being U8. Cairo too has something like that - and it is not a (human-)usable color mode, just one for masking and stuff. Are we sure that part is set correct?