Let's say I have a general implementation to represent a screen. The screen has a footer. The footer can have the following content:
empty or
one button on the left or
one button on the right or
one button on the left and one button on the right
I have at least 20 instances of this screen implementation within my application. I was wondering if it is better to load the buttons with a QML Loader component only if they are used within the given screen or it doesn't make that big of a difference to have the buttons always there just turn on/off their visibility?
Sidenote: each screen knows upfront how many buttons will it need if any.
It wouldn't make a lot of difference in most cases. The trade-back is CPU time vs RAM usage, hiding will save CPU time but use more memory, creating and destroying will save memory but add CPU load.
It would only begin to matter if the components are heavy and complex, which means that they will be slow to create, and use a lot of memory, in that case you have to decide based on which of the two you prefer to avoid.
Unless you already have established to have a problem with how your app performs, don't bother with premature optimizations.
As the title suggests, I'm using Qt for OpenGL drawing, and with QOpenGLWidget I can turn on multisampling for the main screen buffer with QSurfaceFormat's setSamples() function. This works fine and looks pretty nice. However, I'm also drawing into a custom frame buffer (using glGenFramebuffers, glBindFramebuffer(), etc) in the background, where I don't want anti-aliasing (since it's drawing using color encoding for selection purposes), but it seems to be inheriting the multi-sampling from the main QOpenGLWidget somehow. Any ideas on how to disable that, to use multisampling in the main window but not in my own custom off-screen frame buffers?
Multisampled rendering is enabled or disabled by using the glEnable/Disable(GL_MULTISAMPLE). This state is not part of the framebuffer's state; it's regular context state. As such, even when you switch framebuffers, that state will be unaffected.
Additionally, the multisample enable/disable switch doesn't mean anything if your attached images don't have multiple samples. If you're creating images for non-multisampled rendering, there's no reason to create them with multiple samples. So create single-sample images.
Well, couldn't find a way to disable it or avoid it in my OpenGL code, but if I set the default format to have 0 samples and the format of the QOpenGLWidget to have 2/4/8/whatever, then the framebuffer object won't use anti-aliasing when it's created.
I know that topic about multi-select arise at least once, but honestly neither can't find it anymore, nor remember that it had and decent solution.
There are two questions I propose to discuss:
1) Creating a behaviour similar to MS Excel cell's selection. So user click one cell in QTableView and gets clicked cell highlighted and in additional several 'dependant' cells change appearance (get selected or just gets highlighted in any way). In Excel it's widely used to show cell formula dependencies.
I know there are several approaches to solve it. Most simple one is to modify view selection with dependant cell in any of appropriate signal handlers (for example QAbastractModelView clicked()). That way does the job but has ugly side effect, that due to fact that signals delivered after redraw of selected cell occurs so dependant selection is drawn after first cell which produce flickering.
Second approach is go Delegate way.. That's also have some issues because you get paintEvent only for selected cell, so there is not that much you can do about 'dependent' cells. Actually I was able to solve it through this way, by catching on-click, modifying selection and using completely custom delegate which draws everything as soon as complete selection is formed, so actually it skips first redraw, but again I wasn't completely satisfy with results although visually it looked completely right.. mostly because overall TableView response time decreased a lot. Reasons for that is Qt draws native selection right after mouse click received before sending any signals to user classes and in case of this approach paintEvent in delegate arrives after several main loops. So there is a noticeable delay in case of using 'draw selection in delegate' in compare to 'draw native selection'.
I am already starting to think that best option can be completely overwrite most of QTableView to add support for such selection schemas, but may be there are more straight approach?
2) Second question (I put them together because there are something common issues).
Let say you have a grid representing financial information by months and within a month there are several columns of information, so block of N columns repeated M times. Obvious way to make such grid more readable is to use different style for vertical lines in grid for first data column in each month. Let's say to make them 1-2 pixels wider.
As you cannot specify grid style per cell, what I did was to setGrid(false) and then draw my own grid lines as a cell content in delegate.
But then I faced a problems from point 1. Then you instruct Qt to use delegate on certain cell, before delegate will get a paintEvent Qt clears a background of the cell. And in case of hidden grid the background rect which Qt clears is one pixel bigger then required. Probably it can be consider to be a Qt bug because they dont respect grid visibility, but this results in removing grid lines in neighbour cell, so you have to draw in delegate not only cell own grid, but also recalculate proper cell rectangle, check if Qt made a mistake (by analysing QPainter rect), decide if whats being removed from neighbour cell needs restore and repaint it also. This leads to really complicated delegate logic and I cannot consider it to be a decent solution.
So question 2 can be rephrased as do we know a decent way to style a grid per cell in QTableView?
OMG,so many words,can you just pick the most important info?
I'd do something like that:
Create a delegate. Subclass QAbstractTableModel and reimplement data method. Your implementation should return cell text for Qt::DisplayRole, but also can return whatever you want if role is one of your user-defined roles (like font or color or whatever of cell's text. You can use any role number above Qt::UserRole). Your model should emit dataChanged signal to notify QTableView that the content is changed and should be redrawn.
Then in delegate you just request this data using your overloaded QAbstractTableModel::data and draw it the way you want.
I'm implementing Qt's drag and drop API across Windows and X. When I pick up an object in the app running on X and drag it, it leaves a white ghost trail of itself on the window underneath, as if the window underneath is being slow to repaint where the dragged object was previously obscuring part of itself.
I believe that this is symptomatic of the same problem that Qt has just solved with resizing windows causing flicker in child widgets on X windows - i.e. the dragged object is treated as a separate native window and therefore X handles the clipping from the dragged object to the window underneath. Since X does this in a different way to Qt, we get the ghosting effect.
Has anyone experienced the same problems? One solution that comes to mind is to use the same technique as detailed in the blog article linked above and stop the dragged object being treated as a native window, presumably at the cost of drag and drop being limited to my application only (I have no problem with this). Would anyone know how to force drag and drop operations to be internal only?
EDIT: I'm using QDrag::setPixmap to set the graphical representation of the dragged object - it is important that I retain this in favour of a standard drag cursor as this interface is being used on a touchscreen device and will hence have no visible cursor.
I'm now of the opinion that short of editing and then compiling my own build of Qt (not an option for me), I can't force drag and drop operations to be internal only.
Equally, I can't find any way of getting rid of the ghost trail by tweaking my window manager settings or using a compositing window manager (thanks anyway though #atomice). Using OpenGL as the renderer increases the screen repaint speed slightly, but is not perfect and introduces its own problems (see Starting a Qt drag operation on X11 w/ OpenGL causes screen flicker). I would still be very interested to hear any ideas though.
I have, however, got a workaround for my problem which works on both Windows and X. Here's a simplified version:
void DoDrag()
{
//Prepare the graphical representation of the drag
mDragRepresenter = new QWidget(QApplication::activeWindow());
mDragRepresenter->setAttribute(Qt::WA_TransparentForMouseEvents);
mDragRepresenter->SetPixmap(GenerateDragPixmap());
RepositionDragRepresenter();
mDragRepresenter->show();
QTimer UpdateTimer;
connect(&UpdateTimer, SIGNAL(timeout()), this, SLOT(RepositionDragRepresenter()));
UpdateTimer.start(40);
//Start the drag (modal operation)
Qt::DropAction ResultingAction = Drag->exec(Qt::CopyAction);
UpdateTimer.stop();
delete mDragRepresenter;
}
void RepositionDragRepresenter()
{
mDragRepresenter->move(QApplication::activeWindow()->mapFromGlobal(QCursor::pos()) - mDragRepresenterHotSpot);
}
An X11 window is only created for a drag operation if a QDrag::mimeData()->hasImage() is true. If you modify your code so it doesn't use an image then you will just get a drag cursor instead which won't trigger a repaint of the windows underneath.
You don't specify what kind of object you are dragging or how you are setting up the drag operation. Can you add some code to show that?
I'm building my first Flex custom component, in Flex 3. It is a data table based on the 'Grid' container class, with a simple text Label in each cell. (DataGrid and AdvancedDataGrid were not appropriate starting points for my needs.) The component works quite well using smallish tables, but I tried stress-testing it using a larger table, and have been disappointed by the results.
The component creation process has some slow spots, but those are in my power to optimize and aren't my primary concern. What worry me more are what appear to be limitations in the Flex framework itself.
This 'large' sample table has a bit over 7000 cells in it. This is largish, but still 1-2 orders of magnitude less than the biggest I need to accommodate. In standard Grid structure, the main portion of the component consists of a Grid with 400 GridRows of 16 GridItems each, plus a few other smaller ancillary Grids.
Once the table renders, I find the following:
Mouse-related events are slow to fire. Specifically, I have rollOver/rollOut event handlers registered on each table cell, to let me highlight the cell under the pointer. On a small table, I could move the mouse over the table very quickly, and the highlighting would follow the pointer in real-time. With the larger table, the highlighting is very jerky, changing only about twice per second, skipping over many cells.
If I place the mouse cursor over the component and leave it there, my CPU is pegged (one processor core, anyway), and stays that way until I move off of the component, when it drops to idle. My component isn't doing anything at all at this point.
It feels like Flex simply cannot scale to support component trees that are this large. I shudder to imagine how it would behave with 100,000 cells. Perhaps I'm pushing the Grid beyond its intended use, but having an object per table cell doesn't seem like an unreasonable model, and ~14,000 objects in the tree (a GridItem and a Label per cell) seems pretty modest.
I have yet to get useful data out of the FlexBuilder profiler; I'm working on it. For now, my biggest questions are:
Am I really pushing the limits of Flex with this modest test?
Is my approach to this component completely off-base?
I'm running this on Flash Player 9 under Firefox on WinXP.
Yes, Flex is not designed to support very large numbers of components, it is well known that you should minimize the number of components and don't use features that you don't need (Eg. DisplayObject instead of Canvas if you don't need the extra functions).
It's unwise to mirror your data exactly with displayed objects. DisplayObjects (and related classes) are relatively heavyweight, and you need to control how many of those you have.
I would say that the scale you're working at, with 1000+ Cells, and an event listener for each one, would definitely reach Flex's limits.
I think you should take a better look at your approach and architecture. I assume you are not displaying all 1000+ items at the same time, perhaps you should use paging and display 100ish with each screen, with previous/next buttons to move on to another page. You could also consider dynamically adding and removing rows using a custom scrollbar, simulating the scroll effect. This is much more complicated to do.
Boy, it seems we can write a book on this topic. Or atleast a chapter. We learnt quite a few things in this area as we were developing our products.
Bottom line - yes, Flex will slow down to a halt when you add 1000+ "things" on the screen. Here are a few bullet points, and some repetitions of what's already mentioned (just to be concise)
1) Always draw only what is visible. Hans Muller, the architect on the new Spark DataGrid has a great writeup on ViewPorts. http://hansmuller-flex.blogspot.com/2009/06/introduction-to-viewports-and-scrolling.html. So instantiate enough "cells" to fill up the visible area, and basically recycle them as the user scrolls.
2) Recycle, recycle, recycle: Further to above, as the user scrolls, you obviously have to recycle cells that are now out of view to show the ones that are in view. Here there are a few things we learned the hard way :-)
-> Instead of disposing and creating new cells, either use reparenting or use repositioning (prefer repositioning)
What this means is this: Say you have a 10X10 grid (visible) showing a 100X100 data provider.When the user scrolls to cells 20X20, the quickest way will be to set the X and Y of the existing cells to the new locations, and then call set data for each. We used reparenting earlier because our scenario was a series of related containers, so this may not apply to you. But bottom line - we simply move "rows" around the visible area. So creating and destroying will be slow, removing and adding to the display object list will be faster, and just moving around (x,y) will be fastest.
3) Choose what you inherit from wisely: The Flex SDK is a beast. So choose your "cells" base class wisely. For example, the SDK DataGrids, have a lightweight renderer that inherits from UITextField (Halo), as opposed to Label. Even UIComponent will be heavy in certain scenarios. Look up the asdocs for UIComponent and see if you need everything in there, else consider inheriting from further up its hierarchy.
4) Cache Calculations: Do this last in your development cycle. Once you are done with a feature, run flex profiler. Identify the longest running methods, and the most called methods. We always do this when we release, because there's always improvements to be made. There's a lot of math involved when you're developing a highly visual component, and too many calculations will slow things down.
5) Make sure you profile for memory : Unwired event listeners, rogue object references, etc will kill performance. Flex profiler is an excellent tool to combat this, so make sure you use it.
We have some good links here:
http://www.flexicious.com/resources/Ultimate/Docs/LargeDataset.htm?
Hope this helps!
If you look at any List-based control in the Flex framework, you'll see that they make significant use of item renderers which are recycled. So a DataGrid with 20 rows displayed only creates about 22 renderers and recycles them as you scroll through the list. This is why a DataGrid can hold thousands of records and still have pretty snappy performance. I recommend you check out Peter Ent's series of articles on item renderers and take a look at ListBase/List and some of the related classes to understand how to build something similar:
http://weblogs.macromedia.com/pent/archives/2008/03/itemrenderers_p.html
Without seeing your code and knowing exactly what you're trying to do...it definitely seems like you're pushing the limits of Flex by pushing that much data into the framework all at once.
Keep in mind that the Flash runtime wasn't designed to handle huge applications...but run somewhat light applications inside the browser. It also seems unlikely that your users are going to need to have access to all of those controls all at once.
You could try providing data services (Java, .NET, etc.) to drive the data in your application. You would then page through the data so that the framework is only dealing with maybe 200 - 300+ elements at a time.
In flex, if you using Mouse move event to redraw anything .. You might have experienced very slow rendering .
eg:
this.addEventListener(MouseEvent.MOUSE_MOVE, redraw);
and
public function redraw(anything:Object=null):void{
//draw something here
this.graphics.clear();
this.graphics.lineStyle(3, 0x000000);
this.graphics.moveTo(startPoint.x, startPoint.y);
this.graphics.lineTo(endPoint.x, endPoint.y);
this.scaleTextInput.x = centerPoint.x;
this.scaleTextInput.y = centerPoint.y;
}
The Above code results very slow rendering ...
Solution:
Use Event.ENTER_FRAME event instead? Although more resource intensive than the mouse move event, you should receive considerably more updates per second, allowing the mouse to appear more responsive to the user:
Eg:
this.addEventListener(Event.ENTER_FRAME, redraw); instead of
this.addEventListener(MouseEvent.MOUSE_MOVE, redraw);
and You are good to go ..Happy Flexing
More on:
http://www.deepakdhakal.com