I'm using Qt 4.8.4 on Xorg 1.13.1. I'm saving the window geometry in the same way suggested in the documentation:
QSettings settings;
QByteArray geom = widget->saveGeometry();
settings.setValue("widget_geometry", geom);
Also restoring on startup:
QSettings settings;
QByteArray geom = settings.value(buf).toByteArray();
widget->restoreGeometry(geom);
The problem I'm facing is that the window isn't placed in the same position as it was saved. The size is fine. Depending on which window manager I use, the results are different.
In i3, the window is one pixel off on both axes, presumably to make up for the window border.
In Unity (mutter?), no matter where I put the window, it gets nudged over 10 pixels every time it is restored. It also seems to have a y-limit, but I can live with that since it's consistent.
In fluxbox, the window is restored to its saved size and position.
I've done a bit of digging and deconstructed the byte array that is saved into the settings file. I've tried manually adjusting the position of the window instead of using restoreGeometry(), but there's really no way for the application to know what kind of WM inconsistencies it's dealing with. In some WMs, setting the position using the frame geometry instead of the normal geometry works, but screws up other ones. I've read from the Qt geometry documentation that you can't really count on any kind of consistency from X11 window managers, so I'm out of ideas. I'm just hoping some clever person out there has solved this!
Related
I'm using the Firebase-ML barcode decoder in a streaming (live) fashion using the Camera2 API. The way I do it is to set up an ImageReader that periodically gives me Images. The full image is the resolution of my camera, so it's big - it's a 12MP camera.
The barcode scanner takes about 0.41 seconds to process an image on a Samsung S7 Edge, so I set up the ImageReaderListener to decode one at a time and throw away any subsequent frames until the decoder is complete.
The image format I'm using is YUV_420_888 because that's what the documentation recommends, and because if you try to feed the ML Barcode decoder anything else it complains (run time message to debug log).
All this is working but I think if I could crop the image it would work better. I'd like to leave the camera resolution the same (so that I can display a wide SurfaceView to help the user align his camera to the barcode) but I want to give Firebase a cropped version (basically a center rectangle). By "work better" I mean mostly "faster" but I'd also like to eliminate distractions (especially other barcodes that might be on the edge of the image).
This got me trying to figure out the best way to crop a YUV image, and I was surprised to find very little help. Most of the examples I have found online do a multi step process where you first convert the YUV image into a JPEG, then render the JPEG into a Bitmap, then scale that. This has a couple of problems in my mind
It seems like that would have significant performance implications (in real time). This would help me accomplish a few things including reducing some power consumption, improving the response time, and allowing me to return Images to the ImageReader via image.close() more quickly.
This approach doesn't get you back to Image, so you have to feed firebase a Bitmap instead, and that doesn't seem to work as well. I don't know what firebase is doing internally but I kind of suspect it's working mostly (maybe entirely) off of the Y plane and that the translation if Image -> JPEG -> Bitmap muddies that up.
I've looked around for YUV libraries that might help. There is something in the wild called libyuv-android but it doesn't work exactly in the format firebase-ml wants, and it's a bunch of JNI which gives me cross-platform concerns.
I'm wondering if anybody else has thought about this and come up with a better solution for croppying YUV_420_488 images in Android. Am I not able to find this because it's a relatively trivial operation? There's stride and padding to be concerned with among other things. I'm not an image/color expert, and i kind of feel like I shouldn't attempt this myself, my particular concern being I figure out something that works on my device but not others.
Update: this may actually be kind of moot. As an experiment I looked at the Image that comes back from ImageReader. It's an instance of ImageReader.SurfaceImage which is a private (to ImageReader) class. It also has a bunch of native tie-ins. So it's possible that the only choice is to do the compress/decompress method, which seems lame. The only other thing I can think of is to make the decision myself to only use the Y plane and make a bitmap from that, and see if Firebase-ML is OK with that. That approach still seems risky to me.
I tried to scale down the YUV_420_888 output image today. I think it quite similar to the cropping image.
In my case, I will put the 3 byte arrays from the Image.plane for representing the Y,U and V.
yBytes = Image.plane[0]
uBytes = Image.plane[1]
vBytes = Image.plane[2]
Then I convert it to the RGB array for bitmap converting. I found that if I read the YUV array with the original Image width and height by step 2 Then I can scale half of my Bitmap Image.
What should you prepare:
yBytes,
uBytes,
vBytes,
width of Image,
height of Image,
y row stride,
uv RowStride,
uv pixelStride,
output array (The length of output array length should be equal to the output image width * height. For me the size is 1/4 original width and height)
It means if you can find the cropping area positions(The four corner of the Image) in your image, you can just fill the new RGB array with the YUV data.
Hope it can help you to solve the problem.
I'm developing a CAD application using Qt 5.6.2 that is required to run in cheap computers at the same time that it needs to handle thousands of items in the same scene. Because of that, I had to make a lot of experimentations in order to get the best performance.
I decided to create this post to help others and also myself, as long as other people also contribute with more optimization tips.
My text is still a work in progress and I may update it if I discover better techniques (or that I said something really stupid).
Disable Scene Interaction
Event handling is responsible by a good part of the CPU usage by the QGraphicsView engine. At each mouse movement the view asks the scene for the items under the mouse, which calls the QGraphicsItem::shape() method to detect intersections. It happens even with disabled items. So, if you don't need your scene to interact with mouse events, you can set QGraphicsView::setIntenteractive(false). In my case, I had two modes in my tool (measurement and move/rotate) where the scene was basically static and all edit operations were executed by QGraphicsView instead. By doing that, I was able to increase the frame rate in 30%, unfortunately ViewportAnchor::AnchorUnderMouse stopped working.
Reuse Your QPainterPaths
Cache your QPainterPaths inside your QGraphicsItem object. Constructing and populating it can be very slow. In my case it was taking 6 seconds to read a file just because I was converting a point-cloud with 6000 points into a QPainterPath with multiple rectangles. You won't want to do it more than once.
Also, in Qt 5.13 it is now possible to reserve the QPainterPaths 's internal vector size, avoiding multiple copies as it grows.
Simplify your QGraphicsItem::shape()
This method is called multiple times during mouse events, even if the item is not enabled. Try to make it as efficient as possible.
Sometimes, even caching the QPainterPath is not enough since the path intersection algorithm, executed by the scene, can be very slow for complex shapes. In my case I was returning a shape with around 6000 rectangles and it was pretty slow. After downsampling the point-cloud I was able to reduce the number of rectangles to around 1000, that improved the performance significantly but still wasn't ideal since shape() was still being called even when the item was disabled. Because of that I decided to maintain the original QGraphicsItem:shape() (which returns the bounding box rectangle) and just return the more complex cached shape when the item is enabled. It improved the frame-rate when moving the mouse in almost 40% but I still think it is a hack and will update this post if I come up with a better solution. Despite that, in my tests I didn't have any issue as long as I keep its bounding box untouched. If it is not the case, you'll have to call prepareGeometryChange() and then update the bounding box and the shape caches elsewhere.
Test Both: Raster and OpenGL engines
I was expecting that OpenGL would always be better than raster, and it is probably true if all you want is to reduce CPU usage for obvious reasons. However, if all you want is to increase the number of frames per second, especially in cheap/old computers, it worth trying to test raster as well (the default QGraphicsView viewport). In my tests, the new QOpenGLWidget was slightly faster than the old QGLWidget, but the number of FPS was almost 20% slower than using Raster. Of course, it can be application specific and the result can be different depending on what you are rendering.
Use FullViewportUpdate with OpenGL and prefer other partial viewport update method with raster (requires a more strict bounding rectangle maintaining of the items though).
Try to disable/enable VSync to see which one works better for you: QSurfaceFormat::defaultFormat().setSwapInterval(0 or 1). Enabling can reduce the frame rate and disabling can cause "tearing".
https://www.khronos.org/opengl/wiki/Swap_Interval
Cache Complex QGraphicsItems
If your QGraphicsItem::paint operation is too complex and at the same type mostly static, try to enable caching. Use DeviceCoordinateCache if you are not applying transformation (like rotation) to the items or ItemCoordinateCache otherwise. Avoid call QGraphicsItem::update() very often, or it can be even slower than without caching. If you need to change something in your item, two options are: to draw it in a child, or use QGraphicsView::drawForeground().
Group Similar QPainter Drawing Operations
Prefer drawLines over calling drawLine multiple times; favor drawPoints over drawPoint. Use QVarLengthArray (uses stack, so can be faster) or QVector (uses heap) as container. Avoid change the brush very often (I suspect it is more important when using OpenGL). Also QPoint can be faster and is smaller than QPointF.
Prefer Drawing Using Cosmetic Lines, Avoiding Transparency and Antialiasing
Antialiasing can be disabled, especially if all you are drawing are horizontal, vertical or 45deg lines (they actually look better this way) or you are using a "retina" display.
Search for Hotspots
Bottlenecks may occur in surprising places. Use a profiler (in macOS I use Instruments/Time Profiler) or other methods like elapsed timer, qDebug or FPS counter (I put it in my QGraphicsView::drawForeground) to help locate them. Don't make your code ugly trying to optimize things you are not sure if they are hotspots or not. Example of a FPS counter (try to keep it above 25):
MyGraphicsView:: MyGraphicsView(){
...
timer = new QTimer(this);
connect(timer, SIGNAL(timeout()), this, SLOT(oneSecTimeout()));
timer->setInterval(1000);
timer->start();
}
void MyGraphicsView::oneSecTimeout()
{
frameRate=(frameRate+numFrames)/2;
qInfo() << frameRate;
numFrames=0;
}
void MyGraphicsView::drawForeground(QPainter * painter, const QRectF & rect)
{
numFrames++;
//...
}
http://doc.qt.io/qt-4.8/qelapsedtimer.html
Avoid Deep-copy
Use foreach(const auto& item, items), const_iterator or items.at(i) instead of items[i], when iterating over QT containers, to avoid detachment. Use const operator and call const methods as much as possible. Always try to initialize (reserve() ) your vectors/arrays with a good estimation of its actual size.
https://www.slideshare.net/qtbynokia/optimizing-performance-in-qtbased-applications/37-Implicit_data_sharing_in_Qt
Scene Indexing
Favor NoIndex for scenes with few items and/or dynamic scenes (with animations), and BspTreeIndex for scenes with many (mostly static) items. BspTreeIndex allows fast searching when using QGraphicsScene::itemAt() method.
Different Paint Algorithms for Different Zoom Levels
As in the Qt 40000 Chips example, you don't need to use the same detailed drawing algorithm to draw things that will look very small at the screen. You can use 2 different QPainterPath cached objects for this task, or as in my case, to have 2 different point-cloud vectors (one with a simplified subset of the original vector, and another with the complement). So, depending on the zoom level, I draw one or both. Another option is to shuffle your point-cloud and draw just the n first elements of the vector, according to the zoom level. This last technique alone increased my frame rate from 5 to 15fps (in a scene where I had originally 1 million points). Use in your QGraphicsItem::painter() something like:
const qreal lod = option->levelOfDetailFromTransform(painter->worldTransform());
const int n = qMin(pointCloud.size(), pointCloud.size() * lod/0.08);
painter->drawPoints(pointCloud.constData(), n);
Oversize Your QGraphicsScene::sceneRect()
If you are constantly increasing your scene rectangle in size, reindexing can freeze your application for a short period of time. To avoid that, you can set a fixed size or add and remove a temporary rectangle to force the scene to increase to a bigger initial size:
auto marginRect = addRect(sceneRect().adjusted(-25000, -25000, 25000, 25000));
sceneRect(); // hack to force update of scene bounding box
delete marginRect;
Disable the Scroolbars
If the view is flickering when you scrool the scene, disabling the scroolbars can fix it:
setHorizontalScrollBarPolicy( Qt::ScrollBarAlwaysOff );
setVerticalScrollBarPolicy( Qt::ScrollBarAlwaysOff );
Apply Mouse-controlled Transformations to Multiple Items Using Grouping
Grouping with QGraphicsScene::createItemGroup() avoids calling QGraphicsItem::itemChange multiple times during the transformation. It is only called twice when the group is created and destroyed.
Compare multiple Qt versions
I didn't have enough time to investigate it yet, but in my current project at least, Qt 5.6.2 (on Mac OS) was much faster than Qt 5.8.
My application, while not exactly a CAD program, is CAD-like in that it allows the user to construct a "blueprint" of various items in a space, and the user is allowed to add as many items as he likes, and some users' designs can get quite crowded and elaborate, with hundreds or thousands of items present at once.
Most of the items in the view are going to be more or less static (i.e. they move or change appearance only when the user clicks/drags on them, which is rarely). But there are often also a few foreground items in the scene that are constantly animated and moving around at 20fps.
To avoid having to re-render complex static elements on a regular basis, I pre-render all the static elements into the QGraphicsView's background-cache whenever any of them change, or whenever the zoom/pan/size settings of the QGraphicsView change, and exclude them from being rendered as part of the normal foreground-view-redrawing process.
That way, when there are moving elements running around the QGraphicsView at 20fps, all of the very-numerous-and-elaborate-static-objects are drawn (by the code in QGraphicsScene::drawBackground()) via a single call to drawPixmap() rather than having to algorithmically re-render each item individually. The always-moving elements can then be drawn on top in the usual fashion.
Implementing this involves calling setOptimizationFlag(IndirectPainting) and setCacheMode(CacheBackground) on the QGraphicsView(s), and also calling resetCachedContent() on them whenever any aspect of the any of the static-items changes (so that the cached-background-image will be re-rendered ASAP).
The only tricky part is getting all of the "background" QGraphicsItems to render inside the QGraphicsScene's drawBackground() callback, and also to not render inside the usual QGraphicsScene::drawItems() callback (which is typically called much more often than QGraphicsScene::drawBackground()).
In my stress-test this reduces my program's steady-state CPU usage by about 50% relative to the "vanilla" QGraphicsScene/QGraphicsView approach (and by about 80% if I'm using OpenGL via calling setViewport(new QOpenGLWidget) on my QGraphicsView).
The only downside (other than added code complexity) is that this approach relies on using QGraphicsView::setOptimizationFlag(IndirectPainting) and QGraphicsView::drawItems(), both of which have been more-or-less deprecated by Qt, so this approach might not continue to work with future Qt versions. (It does work at least as far as Qt 5.10.1 though; that's the latest Qt version I've tried it with)
Some illustrative code:
void MyGraphicsScene :: drawBackground(QPainter * p, const QRectF & r)
{
if (_isInBackgroundUpdate == false) // anti-infinite-recursion guard
{
QGraphicsScene::drawBackground(p, r);
const QRectF rect = sceneRect();
p->fillRect(rect, backgroundBrush().color());
// Render the scene's static objects as pixels
// into the QGraphicsView's view-background-cache
this->_isInBackgroundUpdate = true; // anti-infinite-recursion guard
render(p, sceneRect());
this->_isInBackgroundUpdate = false;
}
}
// overridden to draw only the items appropriate to our current
// mode (foreground items OR background items but not both!)
void MyGraphicsScene :: drawItems(QPainter *painter, int numItems, QGraphicsItem *items[], const QStyleOptionGraphicsItem options[], QWidget *widget)
{
// Go through the items-list and only keep items that we are supposed to be
// drawing in this pass (either foreground or background, depending)
int count = 0;
for (int i=0; i<numItems; i++)
{
const bool isItemBackgroundItem = (_backgroundItemsTable.find(items[i]) != _backgroundItemsTable.end());
if (isItemBackgroundItem == this->_isInBackgroundUpdates) items[count++] = items[i];
}
QGraphicsScene::drawItems(painter, count, items, options, widget);
}
I read the Qt Documentations, I checked out a couple examples provided with the SDK, I build Qt Creator from source to see how the Qt devs do it...still no luck.
I am developing a cross platform application for Windows and Mac. On the Mac side I can try basically any of my solutions all of them work perfectly (I guess that is a thanks to the MacOS). On the other hand on Windows I always find some kind of bug or sketchy behavior.
Before I go into more details the root of my problems is supporting multiple monitor environments with monitors, which have different resolutions.
My two main solutions in a nutshell:
Since I am writing my application mainly in QML I use ApplicationWindow for my main window. I save the state of my ApplicationWindow in Settings. My code takes into consideration if the previously saved position is still valid (for example if the application was closed while it was on a monitor, which is no longer available)...the only reason why I have to do this because Windows would just open my app's window in "outer space" (Mac handles this automatically). My application (on Windows) gets into a really weird state if I close my application on one of the monitors and then I change the other monitors scaling factor and then I reopen my application. It opens up on the right monitor but it gets way over scaled and the UI elements are just weirdly floating. If I resize the window everything gets back to normal.
I exposed my QML ApplicationWindow to C++ put into a QWidget container, which then I attached to a QMainWindow by setting it as a setCentralWidget. With this method I have access to saveGeometry and restoreGeometry, which automatically takes care of multiple monitor positioning, but the scaling anomaly what I described in 1. still persist.
Did anybody solved this? Thanks in advance for any help and hin
#retif asked for me to provide a writeup when I commented I knew about these types of issues months ago.
TLDR
When dealing with an absolute positioning issue with a Qt Windows on the Windows OS - especially on Windows 10, it's best to be using system-DPI awareness. Some interpolation is required when going from Windows coordinate spaces (at different DPI awareness levels) to Qt coordinate spaces when you are trying to have the best scaling.
Here's what I did on my team's application.
The Problem:
It is really hard to do absolute positioning of a Qt Window when there are multiple monitors and multiple DPI resolutions to contend with.
Our application window "pops up" from a Windows task tray icon (or menu bar icon on Mac).
The original code would take the Windows screen coordinate position of the tray icon and use that as a reference to compute the positioning of the window.
At app startup, before Qt was initialized, we'd set the environment variable, QT_SCALE_FACTOR to be a floating point value of the (systemDPI/96.0). Sample code:
HDC hdc = GetDC(nullptr);
unsigned int dpi = ::GetDeviceCaps(hdc, LOGPIXELSX);
stringstream dpiScaleFactor;
dpiScaleFactor << (dpi / 96.0);
qputenv("QT_SCALE_FACTOR", QByteArray::fromStdString(dpiScaleFactor.str()));
The code above takes the primary monitors "DPI scale" and tells Qt to match it. It has the pleasant effect of letting Qt compute all scaling natively instead of a bitmap stretch like Windows would do in a non-DPI aware application.
Because we initialize Qt using the QT_SCALE_FACTOR environment variable (based on primary monitor DPI), we were using that value to scale the Windows coordinates when converting to Qt's QScreen coordinate space for this initial window placement.
Everything worked fine on single monitor scenarios. It even worked fine on multi-monitor scenarios as long as the DPI on both monitors was the same. But on configurations of multiple monitors with different DPIs, things got off. If the window had to pop-up on the non-primary monitor as a result of a screen change or a projector getting plugged in (or unplugged), weird stuff would happen. The Qt windows would appear in the wrong position. Or in some cases, the content inside the window would scale incorrectly. And when it did work, there would be a "too big" or "too small" problem of the windows scaled to one DPI when positioned on a similar sized monitor running at a different DPI.
My initial investigation revealed that Qt's coordinate space for the different QScreens geometries looked off. The coordinates of each QScreen rect was scaled based on the QT_SCALE_FACTOR, but the adjacent axis of the individual QScreen rects were not aligned. e.g. One QScreen rect might be {0,0,2559,1439}, but the monitor to the right would be at {3840,0,4920,1080}. What happened to the region where 2560 <= x < 3840 ? Because our code that scaled x and y based on QT_SCALE_FACTOR or DPI was relying on primary monitor being at (0,0) and all monitors to have adjacent coordinate spaces. If our code scaled the assumed position coordinate to something on the other monitor, it might get positioned in an odd place.
It took a while to realize this wasn't a Qt bug per se. It's just that Qt is just normalizing the Windows coordinate space that has these weird coordinate space gaps to begin with.
The fix:
The better fix is to tell Qt to scale to the primary monitor's DPI setting and run the process in system-aware DPI mode instead of per-monitor-aware DPI mode. This has the benefit of letting Qt scale the window correctly and without blurriness or pixelation on the primary monitor and to let Windows scale it on monitor changes.
A bit of background. Read everything in this section of High DPI programming on MSDN. A good read.
Here's what we did.
Kept the initialization of the QT_SCALE_FACTOR as described above.
Then we switched the initialization of our process and Qt from per-monitor DPI awareness to system-aware DPI. Th benefit of system-dpi is that it lets Windows auto-scale the application windows to the expected size as the monitors change out from underneath it. (All Windows APIs act as if all monitors have the same DPI). As discussed above, Windows is doing a bitmap stretch under the hood when the DPI is different from primary monitor. So there's a "blurriness issue" to contend with on monitor switching. But it's sure better than what it was doing before!
By default Qt will try to initialize the process to a per-monitor aware app. To force it to run in system-dpi awareness, call SetProcessDpiAwareness with a value of PROCESS_SYSTEM_DPI_AWARE very early in application startup before Qt initializes. Qt won't be able to change it after that.
Just switching to System-aware dpi fixed a bunch of other issues.
Final bug fix:
Because we position our window at an absolute position (directly above the systray icon in the task tray), we rely on the Windows API,Shell_NotifyIconGetRect to give us the coordinate of the systray. And once we know the offset of the systray, we calculate a top/left position to position for our window be on the screen. Let's call this position X1,Y1
However, the coordinates returned from Shell_NotifyIconGetRect on Windows 10 will always be the "per-monitor aware" native coordinates and not scaled to the System DPI. Use PhysicalToLogicalPointForPerMonitorDPI to convert. This API doesn't exist on Windows 7, but it's not needed. Use LoadLibrary and GetProcAddress for this API if you are supporting Windows 7. If the API doesn't exist, just skip this step. Use PhysicalToLogicalPointForPerMonitorDPI to convert X1,Y1 to a system-aware DPI coordinate wel'll call X2,Y2.
Ideally, X2,Y2 is passed to Qt methods like QQuickView::setPosition But....
Because we were using the QT_SCALE_FACTOR environment variable to get the application to scale the primary monitor DPI, all the QScreen geometries would have normalized coordinates that were different from what Windows used as the screen coordinate system. So the final windows position coordinate of X2,Y2 computed above would not map to the expected position in Qt coordinates if the QT_SCALE_FACTOR environment var was anything but 1.0
Final fix to get the final top/left position of the Qt window calculated.
Call EnumDisplayMonitors and enumerate the monitors list. Find the monitor in which X2,Y2 discussed above is positioned on. Save off the MONITORINFOEX.szDevice as well as the MONITORINFOEX.rcMonitor geometry in a variable called rect
Call QGuiApplication::screens() and enumerate these objects to find the QScreen instance whose name() property matches the MONITORINFOEX.szDevice in the previous step. And then save off the QRect returned by the geometry() method of this QScreen into a variable called qRect. Save the QScreen into a pointer variable called pScreen
Final step of converting X2,Y2 to XFinal,YFinal is this algorithm:
XFinal = (X2 - rect.left) * qRect.width
------------------------------- + qRect.left
rect.width
YFinal = (Y2 - rect.top) * qRect.height
------------------------------- + qRect.top
rect.height
This is just basic interpolation between screen coordinate mappings.
Then the final window positioning is to set both the QScreen and XFinal,YFinal positions on the view object of Qt.
QPoint position(XFinal, YFinal);
pView->setScreen(pScreen);
pView->setPosition(position);
Other solutions considered:
There is the Qt mode called Qt::AA_EnableHighDpiScaling that can be set on the QGuiApplication object. It does much of the above for you, except it forces all scaling to be an integral scale factor (1x, 2x, 3x, etc... never 1.5 or 1.75). That didn't work for us because a 2x scaling of the window on a DPI setting of 150% looked too big.
I am trying to implemente a CoverFlow like effect using a QGLWidget, the problem is the texture loading process.
I have a worker (QThread) for loading images from disk, and the main thread checks for new loaded images, if it finds any then uses bindTexture for loading them into QGLContext. While the texture is being bound, the main thread is blocked, so I have a fps drop.
What is the right way to do this?
I have found that the default behaviour of bindTexture in Qt4 is extremelly slow:
bindTexture(image,target,format,LinearFilteringBindOption | InvertedYBindOption | MipmapBindOption)
using only the LinearFilteringBindOption in the binding options speeds up the things a lot, this is my current call:
bindTexture(image, GL_TEXTURE_2D,GL_RGBA,QGLContext::LinearFilteringBindOption);
more info here : load time for a 3800x2850 bmp file reduced from 2 seconds to 34 milliseconds
Of course, if you need mipmapping, this is not the solution. In this case, I think that the way to go is Pixel Buffer Objects.
Binding in the main thread (single QGLWidget solution):
decide on maximum texture size. You could decide it based on maximum possible widget size for example. Say you know that the widget can be at most (approximately) 800x600 pixels and the largest cover visible has 30 pixels margins up and down and 1:2 aspect ratio -> 600-2*30 = 540 -> maximum size of the cover is 270x540, e.g. stored in m_maxCoverSize.
scale the incoming images to that size in the loader thread. It doesn't make sense to bind larger textures and the larger it is, the longer it'll take to upload to the graphics card. Use QImage::scaled(m_maxCoverSize, Qt::KeepAspectRatio) to scale loaded image and pass it to the main thread.
limit the number of textures or better time spent binding them per frame. I.e. remember the time at which you started binding textures (e.g. QTime bindStartTime;) and after binding each texture do:
if (bindStartTime.elapsed() > BIND_TIME_LIMIT)
break;
BIND_TIME_LIMIT would depend on frame rate you want to keep. But of course if binding each one texture takes much longer than BIND_TIME_LIMIT you haven't solved anything.
You might still experience framerate drop while loading images though on slower machines / graphics cards. The rest of the code should be prepared to live with it (e.g. use actual time to drive animation).
Alternative solution is to bind in a separate thread (using a second invisible QGLWidget, see documentation):
2. Texture uploading in a thread.
Doing texture uploads in a thread may be very useful for applications handling large amounts of images that needs to be displayed, like for instance a photo gallery application. This is supported in Qt through the existing bindTexture() API. A simple way of doing this is to create two sharing QGLWidgets. One is made current in the main GUI thread, while the other is made current in the texture upload thread. The widget in the uploading thread is never shown, it is only used for sharing textures with the main thread. For each texture that is bound via bindTexture(), notify the main thread so that it can start using the texture.
I want to create a large CompatibleDC, draw a large image on it, then bitblt part of the image to other DC, in order to achieve high performance. I am using the following code to create compatible Memory DC. But when the rect becomes very large, etc: 5000*5000, the CompatibleDC created become unstable. sometimes it is OK, sometimes it failed. is there any thing wrong with my code?
input :pInputDC
output:pOutputMemDC
{
pOutputMemDC=new CDC();
VERIFY(pOutputMemDC->CreateCompatibleDC(pInputDC));
CRect rect(0,0,nDCWidth,nDCHeight);
CBitmap bitmap;
if (bitmap.CreateCompatibleBitmap(pInputDC, rect.Width(), rect.Height()))
{
pOutputMemDC->SetViewportOrg(-rect.left, -rect.top);
m_pOldBitmap = pOutputMemDC->SelectObject(&bitmap);
}
CBrush brush;
VERIFY(brush.CreateSolidBrush(RGB(255,0, 0)));
brush.UnrealizeObject();
pOutputMemDC->FillRect(rect, &brush);
}
Instead of creating a large DC and then blitting a portion of it another, smaller DC, create a DC the same size as the destination DC, or at least the same size as the blit destination. Then, offset all your drawing commands by the (-x,-y) of the sub section you want to copy. If your destination is (100,200)-(400,400) on the source then create a DC (300x200) and offset everything by (-100,-200).
This has two big advantages: firstly, the memory required is much smaller. Secondly, GDI will clip your drawing operations to the size of the DC (it always clips anyway). Although the act of clipping takes CPU time, the time saved by not drawing pixels that aren't seen more than makes up for it.
Now, if this large DC is something like an image (JPEG for example) then you need to look into other methods. One technique used by many image editing programs is to split the image into tiles and page the tiles to/from memory/hard disk. Each tile is its own DC and you only have enough source DCs to fill the target DC. As the view window moves across the large image, unload tiles that have moved out of the target rectangle and load tiles that have become visible.
Each 5000x5000 pixel image needs ca. 100MB of RAM. Depending on how much RAM your PC has, this might already be the problem.
If you have 1GB of RAM or more, then that's probably not the issue. In this case, you must have a memory leak. Where do you free the allocated bitmap? I see that you unrealize the brush but how about the bitmap?
Note that increasing your swap won't help since that will kill your performance.
Make sure you are selecting all original GDI objects to the DCs.
The problem may be that your Bitmap is still selected into the pOutputMemDC when it is being destroyed and one of them or both can't be deleted properly. Thus problems with memory might begin.