I am amazed at how well the native Symbian components are implemented. One of them is CAknSlider. CAknSlider is a control that has a slider that users can use to slide it along a bar whose orientation can be vertical or horizontal.
Now when you slide the slider the sliding is very smooth and does not flicker. But if for some reason I were to implement a custom slider control I would not get it as neat as CAknSlider.
So my question is how can I figure out how CAknSlider is implemented under the hood. I want to implement a custom slider for my radio application to control the volume of audio stream.
Any idea how should I go about it.
[EDIT: In response to the comment from laalto]
The CAknSlider control is often implemented as a setting item in the settings screen.
I have never seen it implemented as a component control within a compound control container ( like CCoeControl or CAknView ). This is what I have tried so far:
First I created a resource file describing the slider control like below:
RESOURCE SLIDER r_volume_slider
{
layout=EAknCtSlider;
minvalue=0;
maxvalue=10;
step=1;
valuetype=EAknSliderValuePercentage;
minlabel="mute";
maxlabel="full";
}
Then I am using the resource file in my source to create the slider like below:
void CVolumePopupAppView::ConstructL(const TRect& aRect)
{
// Create a window for this application view
CreateWindowL();
InitComponentArrayL( );
iSlider = new ( ELeave ) CAknSlider( );
TResourceReader reader;
iEikonEnv->CreateResourceReaderLC( reader, R_VOLUME_SLIDER );
iSlider->ConstructFromResourceL( reader );
CleanupStack::PopAndDestroy ( );
iSlider->SetContainerWindowL( *this );
iSlider->SetParent( this );
Components().AppendLC( iSlider );
CleanupStack::Pop ( iSlider );
// Set the windows size
SetRect(aRect);
// Activate the window, which makes it ready to be drawn
ActivateL();
}
Now here is the comparison between the CAknSlider as a setting item ( Screenshot1 ) and the CAknSlider that gets created by the above described technique ( Screenshot2 ). Notice that the one I create does not have a percentage value indicator and the minimum and maximum text labels even though I specified them in the resource. The look and feel is also pathetic.
There are lots of techniques to avoid flicker, from double-buffering the whole screen down to more simple optimizations, like only re-drawing the parts of the control that have actually changed. Having appropriate rectangles pre-drawn to blit over where the slider was and its next step is probably the easiest way to do it efficiently.
To find out exactly how CAknSlider does it, you can either:
1) Wait for the relevant package in the Symbian Foundation platform to go open source (EPL) - should sometime in the next 12 months, or
2) Join the Symbian Foundation and get access to the source now
EDIT: (In response to request for more details on graphics optimisation)
Most commonly flicker is caused by redrawing the whole control. I have implemented (via a porting project) some custom controls that don't flicker here:http://developer.symbian.com/main/documentation/porting/#linux2
There's even something a bit like a slider. This example is far from ideal, it doesn't have pre-drawn rectangles for blitting but the graphics are very simple lines and filled rectangles. The concept of overwriting just the changed part is identical though. To blit pre-drawn sections. Draw the backgroud of the slider to an off-screen bitmap and do the same with the movable part of the slider. When the slider is moved, erase the movable part by doing a BitBlt() from the off-screen background (of only the part that needs to be erased) and then BitBlt() the movable part into the new position.
Does that make sense?
You need CAknSlider? steal it! :) CAknSliderSettingPage do everything for us. We, just use that.
iSettingPage = new(ELeave) CAknSliderSettingPage(R_SLIDER_PAGE, iValue);
iSettingPage->ConstructL();
iSettingPage->SetSize(iSettingPage->MinimumSize());
TInt CCustomColorPalette::CountComponentControls() const
{
return 1;
}
CCoeControl* CCustomColorPalette::ComponentControl( TInt aIndex ) const
{
return iSettingPage->SliderControl();
}
Related
Say you have a form that you can expand to the left to show additional controls:
Collapsed:
Expanded:
The simplest way to achieve this in Delphi is to use alRight as the primary anchor for all controls (instead of alLeft) and then simply adjust the width and X coordinate of the form. Either you can set the Width and Left properties individually, or you can use a function that sets them simultaneously, like
if FCollapsed then
SetWindowPos(Handle, 0, Left - Width, Top, 2 * Width, Height, 0)
else
SetWindowPos(Handle, 0, Left + Width div 2, Top, Width div 2, Height, 0)
The problem is that there is quite noticeable flickering in the always-visible part of the form (in this example, the buttons) while expanding or collapsing. Try it yourself!
It is possible for the operating system to resize the form to the left without any flickering at all -- just grab the left edge of the form using the mouse and drag the mouse to the left or right -- but I am unable to find any function in the Windows API that exposes this kind of resizing.
I have tried to use several different Windows API functions to resize and reposition the form, tried their various parameters (for instance, the SWP_* flags), tried LockWindowUpdate, WM_SETREDRAW, TForm.DoubleBuffered etc. to no avail. I also examined the possibility to use the WM_SYSCOMMAND SC_SIZE approach.
I am not yet sure if the problem lies at the OS level or the VCL level.
Any suggestions?
Edit: I am very surprised to see that this Q received close votes. Let me try to clarify:
Create a new VCL forms application.
Add a few buttons to the right side of the main form and a memo to the left. Set Anchors to [alTop, alRight] on all controls. On the OnClick handler of the buttons, add the following code:
if FCollapsed then
SetWindowPos(Handle, 0, Left - Width, Top, 2 * Width, Height, 0)
else
SetWindowPos(Handle, 0, Left + Width div 2, Top, Width div 2, Height, 0);
FCollapsed := not FCollapsed;
where FCollapsed is private boolean field of the form (initialized to false).
Now, click the buttons repeatedly. (Or give one of them keyboard focus and hold the Enter key for a few seconds.) You will probably notice that the region with the buttons on your monitor will not display a perfect still image, but will flicker. In addition, you might actually see 'ghosts' of the buttons to the left of the actual column of buttons.
I am unable to capture this millisecond flickering using screen capture, so instead I used a digital camera to record my screen:
https://privat.rejbrand.se/VCLFormExpandFlicker.mp4
In this video clip, it is apparent that the column of buttons isn't a static image on the screen; instead, for a few milliseconds each time the form is resized, this region is something else than it should be. It is equally apparent that there is a 'ghost' column of buttons to the left.
My question is if there is any reasonably simple way to get rid of these visual artefacts (that at least to me are very visible even if you expand/collapse the form a single time).
On my Windows 10/Delphi 10.1 computer at work, the form is resized in a perfect manner when I drag its left-most edge using the mouse: the unaffected client area of the form is perfectly static on the monitor. However, on my Windows 7/Delphi 2009 PC at home, I do see that there is a lot of repositioning going on when I do this.
I can provide some insight about why you see ghost images of the other half of your UI and possibly a way to stop it. The ghost image indicates that someone is copying your client area pixels (and copying them to the wrong place, always flush-left in your window) before you have a chance to redraw them with the correct pixels.
There are likely two different, overlapping sources of these ghost pixels.
The first layer applies to all Windows OSes and comes from a BitBlt inside SetWindowPos. You can get rid of that BitBlt in several ways. You can create your own custom implementation of WM_NCCALCSIZE to tell Windows to blit nothing (or to blit one pixel on top of itself), or alternately you can intercept WM_WINDOWPOSCHANGING (first passing it onto DefWindowProc) and set WINDOWPOS.flags |= SWP_NOCOPYBITS, which disables the BitBlt inside the internal call to SetWindowPos() that Windows makes during window resizing. This has the same eventual effect of skipping the BitBlt.
However, Windows 8/10 aero adds another, more troublesome layer. Apps now draw into an offscreen buffer which is then composited by the new, evil DWM.exe window manager. And it turns out DWM.exe will sometimes do its own BitBlt type operation on top of the one already done by the legacy XP/Vista/7 code. And stopping DWM from doing its blit is much harder; so far I have not seen any complete solutions.
For sample code that will break through the XP/Vista/7 layer and at least improve the performance of the 8/10 layer, please see:
How to smooth ugly jitter/flicker/jumping when resizing windows, especially dragging left/top border (Win 7-10; bg, bitblt and DWM)?
Since you have multiple child windows, the situation is even a little more complicated. The BitBlt type operations I mentioned above happen on your whole top-level window as a whole (they treat the window as one set of pixels regardless of how many windows are underneath, and regardless of CLIPCHILDREN). But you need to have windows move atomically so that on the next redraw they are all positioned correctly. You may find BeginDeferWindowPos/DeferWindowPos/EndDeferWindowPos useful for that (but only go there if the above tricks do not work).
I am using Unity 5 and I started to make a menu scene. When I made the canvas, all of values under the Rect Transform component are locked and it says "some values driven by Canvas." The only thing I can change is the z position when using the gizmo in the editor. I can't reset the position or anything. Why is this happening?
This means that the canvas's canvas component has it's render mode set to Screen space - overlay. This forces it to be the size of the screen. Change it to World Space and it will allow you to resize it and move it around.
Changing the Render mode is not an ideal solution; neither is Overlay mode the reason why this is happening at all. World Space is just a render mode that changes the way your whole UI behaves and would mean a whole different set up and a whole lot more work just to get a child UI object to move independently.
Here is the description of what World Space is for from the Unity site:
In this render mode, the Canvas will behave as any other object in the
scene. The size of the Canvas can be set manually using its Rect
Transform, and UI elements will render in front of or behind other
objects in the scene based on 3D placement. This is useful for UIs
that are meant to be a part of the world. This is also known as a
“diegetic interface”.
The Rect Transform usually gets locked because it is a child of another Canvas Object which controls its Transforms. The way to fix this is to overwrite it by adding a “Layout Element” component to it. From there you can configure it to work the way you like and it can have transforms independent of the Parent UI Object.
For full details, see this Unity support page: https://support.unity3d.com/hc/en-us/articles/115000179163-How-to-overwrite-Width-and-Height-values-that-are-driven-by-a-Layout-Group-in-runtime-
Canvas is depend on game tab in your window panel.
Adjust panel by use of close tab or resize panel or doc game panel.
It will help you make default 800 X 600 canvas.
The new Unity 4.6 comes with a new GUI, when I change de resolution on Unity the UI Button scales perfectly but when I test on the Nexus 7 device the Button looks too small. Any idea how to solve this?
Unity's new GUI system uses "anchors" to control how gui elements (like buttons) scale in relation to their parent container.
Unity has a tutorial video on how to use the new "Rect Transform" component (where the anchors are configured) here: http://unity3d.com/learn/tutorials/modules/beginner/ui/rect-transform.
The last half of the tutorial is all about anchors. That page has links to the entire tutorial series. It's not too long. You should watch the whole thing.
Specific to your question:
The anchors are visible in your first screen shot. They are those 4 little arrows at the top left of your button.
Right now, your button is only anchored by it's top left corner.
The two right anchors need to be dragged to the right so that the right edge of your button is anchored to a space inside its parent container.
Depending on your situation, the two bottom arrows may need to be dragged down so that the bottom edge of your button is anchored as well.
The video I linked above covers all this in detail.
Lastly, for the font size to scale nicely on different resolutions, you will need to add and configure a reference resolution component to the base canvas of your UI, as Ash-Bash32 wrote earlier.
Update: The best way to add a Reference Resolution component is through the inspector window for the base canvas in your UI.
1) click the "Add Component Button" at the bottom of the inspector.
2) type the word "Reference" in the search filter field.
3) select the "Reference Resolution" component in the search results.
The Reference Resolution is now renamed as Canvas Scaler.. Along with the renaming they have added many more features for the dynamicity of the Canvas. You can go through the Unity Doc of Canvas Scaler and also take a look at this article for a practical example of how and why to use Canvas Scaler. Also make sure you use the Anchor Points to good effect to make this more robust...
To Scale UI added the ReferenceResolution Component to the Canvas you want to scale.
P.S. Theres no Documention for ReferenceResolution
If you want the button to be the same size for all screens and resolutions, you have to add the canvas scaler component to the canvas and the set the screen match mode to: match width or height, here is the link to the docs, this helps a lot if you want to aim to different sizes or resolutions:
http://docs.unity3d.com/Manual/HOWTO-UIMultiResolution.html
This becomes giant and convoluted once you start laying things out in code AND using a canvas scaler, so I wish to provide a thorough answer to save someone the hours I went through.
First, don't use anchoredPosition to position anything, unless you fully realize it is a 0.0 to 1.0 number. Use the RectTransform localPosition to do the actual laying out, and remember it's in relation to the parent anchor. (I had to lay out a grid from the center)
Second, put a canvas scaler on the parent layout object AND the inner ui pieces. One makes the layout in the right position, the other will resize your elements so they actually show up right. You can't rely on the the parent unless the children also have scalers (and Graphic Raycasters to touch them).
Third, if you have a scaler, DON'T use Screen.width and height, instead assume the screen is the same value you put for the scalers (hopefully you used the same, or know what you're doing). The screen width always returns the actual device pixels, retina devices too, but the canvas scalers DO NOT account for this. This probably gives unity the one remaining way to find actual screen dpi if your game wants it. Edit: This paragraph applies to any parent canvas connected to the code doing your laying out. Not stray canvases, you can probably mix it up. Just remember unity's guidelines on performance with canvases.
Fourth, the canvas is still a bit buggy. Even with the above working, some things don't render until you delete and recreate a canvas, if you re-open the scene or it crashes. Otherwise, the above is the general "rules" I've found.
To center a "grid of things" you can't just use half of the canvas scaler's width or height, you have to calculate the height of your grid and set the offset by half of it, otherwise it will always be slightly off. I just added this as an extra tip. This calculation works for all orientations.
When developing using cocos2d-x 3.x for a device, it automatically sets the GL view to fit the device. In VS2012 on windows, it creates a seemingly-arbitrarily sized window. How do I set the size of that window?
My solution was as follows.
In AppDelegate.cpp:
bool AppDelegate::applicationDidFinishLaunching() {
auto director = Director::getInstance();
auto glview = director->getOpenGLView();
if(!glview) {
glview = GLView::create("My Game");
glview->setFrameSize(800, 600); // or whatever
director->setOpenGLView(glview);
}
...
}
In my particular use case, I'm setting the window sizes to various resolutions and aspect ratios to test my layouts. I'm sharing Q&A format because I couldn't find a straight answer to this anywhere.
+1 to Tom. Also, I would just like to share my answer and experience to everyone.
Remember, do not set the screen size "AFTER" the director set the GL view. This causes some problem with bounds detection on some nodes most notably cocos2d::ui::Button and other ways on how create buttons. I am using cocos2d-x v3.6
Check my answer here:
cocos2d::Menu click detection is a bit off to bottom left whenever using a custom window size
Doing this way will cause some problem:
auto director = Director::getInstance();
auto glview = director->getOpenGLView();
if(!glview) {
glview = GLViewImpl::create("My Game");
director->setOpenGLView(glview);
}
director->getOpenGLView()->setFrameSize(width , height);
Clicking the button, doesn't kick in the callback. Which is frustrating. Probably out of your frustration as well you click all through out the screen and notice there are some part of the screen (most likely bottom left part) which triggers the callback as if the bounding box of the node lies there. It doesn't even match the position and the size of the node in question. I can reproduce the problem whenever I change the screen size like the one I describe above. So never ever do it like that.
Tom's answer is the correct way of changing screen size.
I hope this will deter anyone doing it this way. I swear to God, this post could have save me heck of time solving this.
Cheers!
I've been banging my head about this seemingly easy task and I could really use some help.
I have a wide Image loaded in the gui (using the designer..) and I want to be able to draw only a portion of it, a rectangle.
I need to be able to change this rectangle position over the large image, in order to draw a different part of the larger image at will. In this process the rect must maintain its size.
Using the Ui::MainWindow object I'm able to access the label holding the image and a solution that involves using this option is preferred (in order to keep up with the rest of the code I've already written )
Any solution will be much appreciated :)
Thanks,
Itamar
I would definitely (for ease of use) just place an empty label as placeholder in Designer.
Then implement the paintEvent for this label (delegate it to your own method). You'll have also have to look into QPainter, QPixMap, etc... Should be doable based on these hints and the documentation.
If you want more, I suggest you provide a small code snippet to work upon.
If you want to do this more or less purely through designer, you could put a QScrollArea where you want the portion of the image to appear. If you set the scroll area's scrollbar policy to be never shown, you can then manually change what part is visible via the scroll area widget. However, this would probably be more complex that creating a derived widget and reimplementing the paint function.