I am writing an application that must display images, and potentially loads of them. So I was wondering if there is a proper way of having a QGraphicsScene use OpenGL, and in case it fails, use a software renderer.
I've read the documentation, but what if setting the viewport fails?
You're talking about more than a gigabyte of textures. OpenGL by itself is of no help here, neither is a raw QGraphicsScene. You'll need to dynamically cache the images, ideally with prediction based on scrolling direction and speed. You'll need a coupling layer between each view and the scene, to keep the scene populated with images that are visible or will be soon visible in each view. Once you do that, OpenGL may help but you absolutely need to profile things and prove to yourself that it helps. Even without OpenGL you can have very decent performance.
Related
I have used OpenGL pretty exclusively for all my rendering, to the point that I'm unaware of any other way to write pixels to a window unfortunately.
This is a problem because my current project is a work tool that emulates an LCD display (pixel perfect, 2D, very few pixels are touched each frame, all 'drawing' can be done with memcpy() to a pixel buffer) and I feel that OpenGL might be too heavy for this, but I could absolutely be wrong in that assumption.
My goal is to borrow as little CPU time as possible. What's the best way to draw pixels to a window, in this limited way, on a modern typical machine running windows 10 circa 2019? Is OpenGL suited for this type of rendering, or should I adopt another rendering method in this case? And if so, what would that method be?
edit:
I should also mention, OpenGL can be used right away for me. If rendering textured triangles with an optimal setup is the fastest method, then I can already do that. Anything that just acts as an API over OpenGL or DirectX will likely be worse in my case.
edit2:
After some research, and thanks to the comments, I think I may just use OpenGL with Pixel Buffer Objects to optimize pixel uploads and keep rendering inexpensive.
I am looking for a way to create an updating texture from iOS to an OpenGL Context. I have seen Render contents of UIView as an OpenGL texture but this is quite slow, as it requires the whole view to be rerendered every time it changes. This means webviews in particular are hit very hard as the whole page needs blitting around. This breaks animations in web views, and makes everything very static. I was wondering if there is a technique using some other APIs in iOS that would enable a link to be created between view to texture (much like video textures do).
This seems to be a fundamental requirement of OS display composition, but it feels like it always happens under the covers and is not exposed to developers. Perhaps I am wrong!
Bonus points for anyone that can tell me if any other OSes support this feature.
Take a look at RosyWriter sample project form Apple.
It uses CVOpenGLESTextureCache to improve performance of rendering camera frames as opengl textures.
I am creating a video player application and I was wondering what would be the optimize way to handle the media changing action.
For now I am using 2xPBOs as explain here: OpenGL Pixel Buffer Object (very awesome website by the way) and some textures. In order to keep perfect colour and aspect, I need my PBOs and my textures to be the same size as my video clip. (The resize is done only once during the shadder stage).
So basically, if the actual media is like 1920x1080 but the next one on the playlist is 1280x720 what should I do? I am thinking of 2 solutions right now:
Resizing PBOs and Textures on the fly
Recreating everything, my whole OpenGLPreviewWidget
I know the solution 1 is include in solution 2 but, should I recreate a openGL context, windows, etc. or, because it's too slow, just resizing would do it?
Creating a new context is a fairly heavy weight operation, at least compared to most other things you would do when you use OpenGL. So unless you have a good reason why you need a new context, I would avoid it.
Re-allocating the PBOs and objects is easy enough. As you already pointed out, you'll end up doing this in either case. If that alone is enough, I think that's the way to go.
My basic problem is to generate 2d renders of 3d objects, such as one could accomplish with openGL or DirectX. However I have no interest in displaying the rendered objects to the screen, only to generate the shaded/ textured/ rotated images as bitmaps (not necessarily written to disk). This process is likely to be a problematic bottleneck in my design, so I would prefer to keep my solution as compact as possible (ie, don't waste the time sending the image to the screen), and would be most pleased if I could make use of hardware-accelerated rendering. Does anyone know of a convenient library or tool to help in this?
Right now I would prefer a C/C++ option, however speed is what I'm going for, so I'm willing to deal with ASM/ super optimized anything if it gets what I want the fastest.
What you need is a so called technique "rendering to texture". With OpenGL you can do it very easy. Take a look at example here: http://www.songho.ca/opengl/gl_fbo.html#example
You can do this using "render to texture"
This process is likely to be a problematic bottleneck in my design, so I would prefer to keep my solution as compact as possible (ie, don't waste the time sending the image to the screen)
If you want rendering to be fast, you want to use the GPU for this. Sending a image to the screen comes for free with those things. But reading an image back to the CPU memory, that is actually quite a bottleneck. But unavoidable in you case probably.
I am currently using a QGraphicsItem that I am loading a pixmap into to display some raster data. I am currently not doing any tiling or anything of the sort, but I have overriden my QGraphicsItem so that I can implement features like zooming under mouse, tracking whick pixel I am hovering over, etc etc.
My files that are coming off the disk are 1 - 2GB in size, and I would like to figure out a more optimal way of displaying them. For starters - it seems like I could display them all at once if I wanted - because the QImage that I am using (Qpixmap->QImage->QgraphicsItem) seems to fail at any pixel index over 32,xxx (16 bit).
So how should I implement tiling here if I want to maintain using a single QGraphicsItem? I dont think I want to use multiple QGraphicsItems to save the displayed data + neighboring data "about" to be displayed. This would require me to scale them all when the person moused over and tried to scale a single tile, and thus causing me to also have to reposition everything, right? I guess this will also require having some knowledge about what data to exactly get from the file.
I am however open to ideas. I also suppose it would be nice to do this in some kind of threaded way, that way the user can keep panning the image or zooming even if all the tiles are not loaded yet.
I looked at the 40000 chip demo, but I am not sure that is what I am after - it looks like it basically still displays all of the chips like you normally would in a scene, just overrode the paint method to supply less level of detail...or did I miss something about that demo?
It's not too surprising that there would be difficulty handling images that size. Qt just isn't designed for it and there are possibly other contributing factors due to the particular OS and perhaps the way memory is managed.
You very clearly need (or at least, should use) a tiling mechanism. Your main issue is that you need a way to access your image data that does not involve using a QImage (or QPixmap) to load the entire thing and provide access to that image data since it has already been determined that this fails.
You would either need to find a method (library) that can load the entire image into memory and allow you to pull regions of image data out of it, or load only a specific region from the file on disk. You would also need the ability to resize very large regions to lower resolution sections when trying to "zoom" out on any part of the image. Unfortunately, I have never done image processing like this so am unfamiliar with what library options are available, Qt likely won't be able to help you directly with this.
One option you might explore however is using an image editing package to break your large image up into more manageable chunks. Then perhaps a QGraphicsView solution similar to the chip demo would work.