Recent searches
Search options
Here's another Megapixels 2.0 update.
https://blog.brixit.nl/megapixels-2-0-progress/
This edition comes with some wonderful GTK breakage...
@martijnbraam Regarding the gtk breakage, it seems like it should be possible to bypass gtk, and create an opengl context directly? I did a little research and this seemed potentially relavent: https://discourse.gnome.org/t/gtk4-and-legacy-opengl/25980.
If you do replace gtk, would sdl be an option? It seems more minimal and less likely to break opengl.
If there's no progress in the next couple of weeks, I'll free up some time to see if I can help, although I don't have much direct experience to add.
@aren I've done a few SDL things before and that might work. But yeah that would be a massive rewrite...
I hope making your own context in a GTKGLArea widget won't blow up in horrific ways when you're running on a platform that actually has a GL version GTK4 supports
@martijnbraam True, I don't know if gtk or opengl rely on global state... I guess you could always attempt to get a context through gtk and only fall back to doing it manually if that doesn't work.
@martijnbraam GTK prefers GLES over GL these days and GLES 3.0 is the baseline now, like in Firefox (which never enabled HW acceleration for GL(ES) 2.x).
I can see that this is quite unfortunate for the PinePhone and Librem 5. But then GLES 3.0 is almost 13 years old and even a Thinkpad x220 from ~2012 supports it just fine - and that certainly doesn't count as "latest and greatest Macbooks".
AFAIK there's a certain chance that etnaviv will support GLES 3.0 eventually on the Librem though
@martijnbraam I personally would also love GLES 2.0 era hardware to stay supported, but having worked on that myself in Mutter I can definitely see why GTK folks decided that it's just getting too much into the way - especially when you refactor things in ways that suit modern renderers.
@rmader it seems like that in the case of GTK the entire "old GL" stuff was a seperate backend, why not just not remove that backend so older hardware at least have _something_. Especially since it's the older hardware that needs acceleration the most.
@martijnbraam AFAIK it's not that easy. You can't just keep a backend sitting there when you add new features and restructure things - it's a constant source of work. Firefox dropped the GL 2.x renderer years ago for good reasons.
For the specific case of Megapixels I suppose switching to QT might be the best option indeed, assuming there are enough users in the embedded space to ensure GLES 2.0 stays supported for another couple of years :/
@martijnbraam awesome stuff! Impressive work on the camera front, is this all based on reverse engineering the camera?
@vancha Nah this camera stuff is all based on (sparse) documentation on the various components, luckily :P
@martijnbraam I did not expect to see an htc dream in that thumbnail photo
@martijnbraam Do you really need a full blown toolkit? Can't you use native wayland. Seeing as how that you're already doing the complex part of rendering into a buffer using OpenGL, talking to the compositor directly and creating the toplevel should be much simpler. You only have a few buttons on top of that, right?
@whynothugo yeah that's an interesting option, I can just draw the rest of the UI bits in GL. Would be a bit more annoying when dealing with the settings panel, that has actual controls like dropdowns to deal with...
Because might be able to keep GTK for the popup, and then raw OpenGL in the toplevel.
@martijnbraam The setting panel could potentially be a child process which uses gtk. No need to intertwine gtk and opengl; can keep them separate.