Why would you need a viewport? Isn't a View engough? What is the difference?
I have one viewport in my program created so long ago that I forgot it was even there... And now that I want multi-staged rendering and I wonder if I need another one. And the Viewport mdocs page doesn't get into how and why (or maybe I'm blind).
A viewport is how much of the window a view takes up.
A view is what should be visible in that viewport.
A good scenario of having many viewports would be in a splitscreen game.
In a splitscreen game, each player has their own section of the screen. The game can not render one players view inside another players viewport.
Many viewports can also be useful in singleplayer games, like to render a minimap.
Many viewports can also be useful outside of games, like in a text editor. You could have one viewport for the text, and the other for a toolbar.
Think of each window on your computer as being a viewport. You could be in an application that has scrolling, but that is the view moving, not the viewport. When you resize the window, or move the window, you are moving the viewport on your screen - not the view.
Related
Let's say you have a resizable window with child scrollbar controls, and the scrollbars come and go depending on whether the window contents are large enough to require scrolling.
When both scrollbars are present, a small rectangle is effectively created in the bottom right corner of the window, at their intersection. Is there a clean strategy for clipping that rectangle when drawing on the window, so that you don't paint on it?
I guess my current approach is to obtain the rectangles for each scrollbar, and if those rectangles are not null, then use the rectangles' locations to determine the rectangle that we want to clip. And then call ExcludeClipRect for that rectangle. I guess a similar approach could be used, except with GetSystemMetrics(SM_CXVSCROLL) and GetSystemMetrics(SM_CYVSCROLL) to get the rectangle dimensions.
But is there a more accepted way of doing this, perhaps using some helpful clipping API functions? Thank you for any input.
Is there any way of confining the rendering of CCSprites and such onto a CCLayer in a way that anything beyond the frame of the CCLayer gets clipped (ie. doesn't display past the frame of the CCLayer)?
Why do I need this? I'm working on a roguelike and want a modal box to appear to select spells, wands, potions or scrolls. I place a CCSCcrollView on top a CCLayer to scroll through the lists but I need to confine the display to just the region I want.
I am writing a scheduling-type application using Qt/C++ and want to display weekly schedules in one part of the window, and have this rendering scale as the window size increases. The renders will be composed of rectangles with text in them, and as the display area increases the rectangles should scale nicely while the text should remain the same size.
I have experimented with QGraphicsScene and QGraphicsView and I can make rectangles and text scale; however, the rectangle scaling seems ugly (stretches the outline) and I don't want text to scale at all.
I suspect that I might want to resize the scene to the display area and re-draw the rectangles and text; however, I am not sure how to do this - QGraphicsScene doesn't seem to respond to resizeEvent. Is this even the right approach?
I'm not sure what the ugly rectangle scaling is about (a screenshot might help me understand better what you meant there), but if you don't want the text parts to scale, you can accomplish that by calling setFlag(ItemIgnoresTransformations, true) on your QTextGraphicItem objects.
As far as automatically rescaling the rectangles in response to a window resize, you might take a look at the documentation of the QGraphicsView::fitInView() method:
Scales the view matrix and scrolls the scroll bars to ensure that the
scene rectangle rect fits inside the viewport [...] It's common to
call fitInView() from inside a reimplementation of resizeEvent(), to
ensure that the whole scene, or parts of the scene, scales
automatically to fit the new size of the viewport as the view is
resized. Note though, that calling fitInView() from inside
resizeEvent() can lead to unwanted resize recursion, if the new
transformation toggles the automatic state of the scrollbars. You can
toggle the scrollbar policies to always on or always off to prevent
this (see horizontalScrollBarPolicy() and verticalScrollBarPolicy()).
I have two QGraphicsView that are of equal width, one ontop the other in a Vertical Layout.
When I re-size my application window, the QGraphicsView on the bottom does what I expect, it remains at the exact position it started at, however the top view begins to move the scene to the right exposing coordinates that are below x=0(essentially blank padding on the left edge of the View), which I do not want, I need both to behave the same because they correspond to each other.
I must have missed something, because should these views behave exactly the same? I need them to align, as the top view has hidden scroll bars and scrolls horizontally by however much the bottom view is scrolled.
Make sure your resizeAnchor is set to NoAnchor and alignment is Qt::AlignLeft | Qt::AlignTop. You may need to try some other combination to work with your situation.
I have a QGraphicsView and a slide show of QGraphicsScenes, at the moment when the user switches to the next slide I just change the Scene that the View is looking at and it changes instantly to reflect that.
What I would like to do it create some transition effects, such as the rotating cube or the slide in/out.
However looking at the QPropertyAnimation class it seems to be about moving an object not transitioning from one to another.
As in I would need a view for each scene and then transition between each view.
What other strategy could I employ?
Instead of changing the scene that the view sees, you could use property animations to slide graphic items in and out of the view from a single scene. That would give you the slide in/out transition without too much effort. The rotating cube effect would be trickier but I think a reasonable facsimile could be produced with property animations.
You could also simulate other effects by subclassing the view widget and adding some custom properties that you could animate and use to direct background or foreground painting.