My app has a toolbar which is normally 64 pixels height. On OS X (with a retina display) the toolbar's height still equals to 64 (logical) pixels.
If I pass 64x64 bitmap when creating a wxBitmapButton I get a blurry image (which is expected), so I need to pass somehow a 128x128 bitmap.
When I pass it, it's just shown cropped without proper scaling. So how can I use wxBitmapButton to show high-quality bitmap?
I know this is a rather old question by now, but there is finally a good answer to it now if you're using the latest versions of wxWidgets from Git or 3.1.6+ once it will have been released.
The answer consists in using wxBitmapBundle which is basically a smart container for bitmaps to be used in different resolutions/at different DPI scale factors. In the simplest case, which is sufficient under Mac, you just need to create a bundle from the two bitmaps, to be used at normal (or 100%) and high (or 200%) DPI by using wxBitmapBundle::FromBitmaps(bmpNormal, bmpHigh) and pass this object to wxBitmapButton::SetBitmap().
This also works with wxToolBar tools, wxStaticBitmap and other (although not yet all) classes. And the bitmap bundle can be created from resources, which is especially convenient under Mac, as you can just have normal.png and normal#2x.png files in your application bundle (which has nothing to do with wxBitmapBundle, it's just an unfortunately overloaded term) Resources subdirectory.
Related
I've read many questions about this, but they don't satisfy what I'm trying to do. I'm trying to use a TTF file for the text's font on my application, I thought of using Direct Draw, but the tutorial from Microsoft website only explains how to use it with Direct2D. How am I supposed to load data from this file and render text for my Direct3D application using this file's font? I've also read about the AddFontResourceExA() function, but I didn't find any content of how I could use this. I'm really lost here, so any help is appreciated.
There are basically two approaches for rendering text on a Direct3D 11 Render Target / Texture.
Rendering using a 'sprite sheet'. Here you capture the font at a particular resolution and generate a texture from it. Then you use the texture to render the glyphs as textured triangles. This is very fast and inexpensive to render, but does not scale to arbitrary resolutions (you can capture the 'sprite sheet' at multiple point sizes to get some scaling) and does not work well with "CKJ" languages due to the large size of the fonts. For an example of this, see SpriteFont in the DirectX Tool Kit. This is what legacy D3DX9/D3DX10 did as well.
Rendering using vector fonts directly. Here you have some kind of library that generates triangles 'on-the-fly' from the "TrueType" vector font data. This is what Direct2D+DirectWrite is designed to do. You can use interop with Direct3D 11 surfaces, but essentially you are using DirectWrite -> Direct2D -> shared texture. Then you draw the shared texture with Direct3D as a 'sprite'. This is more complicated to setup, but results in arbitrary resolutions scaling, support for large character set fonts, and handles complex writing systems.
wxWidgets 3.1 claims to fix the Windows High DPI issues. It works too but I see blur UI (fonts/bitmaps) looks stretched.
I went through the https://learn.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows
I did the manifest changes to make my application DPI-aware, it removed the blur effect but application layout went wrong, every layout looks smaller (unusable UI).
Note* issue more vigilant on 3K and 4K system. Hardcoded pixel sizes are not scaling (like 400px width button, 500pixel width panel etc).
wxWidgets gives you a (relatively simple) way to make your application work in high DPI, but doesn't -- and can't -- do it automatically for you, in particular only sizer-based layouts without hardcoded pixel sizes will work correctly and you do need to provide your own higher definition artwork.
Concerning the existing pixel values, the simplest (even though not really the best) way to make them work better is to put FromDIP() calls around them.
Also note that you don't need to do anything special for pixel values in XRC, they're already interpreted as being resolution-independent pixels and are scaled according to the DPI automatically.
Old-school computer graphics sometimes produced animations (cycles and fades) without actually redrawing anything to video memory, purely by updating the color palette.
Is it possible to do this in an animated gif? That is, optimise (reduce file-size of) the gif by only providing a single frame of (significant) raster content, but have each (delayed) animation frame update colour values in the (global) palette?
The short answer is no.
According to the existing standard, every GIF frame containing a local palette must have its own data to be displayed using that palette, otherwise the local palette is of no use.
One of the possible solutions is to define your own GIF Application Extension block (like Netscape did; see the link) to store additional palettes and their time delays. Apparently, those extension blocks should appear after frames whose data they affect.
The downside of this approach is that no one except your decoder would support palette cycling unless your block type somehow makes its way to become a new de-facto standard.
Nevertheless, your handcrafted GIFs would remain valid for all other GIF decoders (even though without any palette cycling), as the standard requires them to silently ignore any GIF Application Extensions with IDs unknown to them.
I'm writing a wxWidgets (3.1.0) app that is supposed to work on windows and mac.
On windows when i set the scaling of the text to more than 100% the sizes of my controls get all messed up. I have a dpi manifest that says my app is dpi aware. I also set the font pixel size on my dialogs and that works to some extent. When i set the size of some element from code it is resized to that pixel size which is what i need, but any size that is set in the xrc file gets scaled up. Also when i try to reduce the size of any wxSpinCtrl it can be reduced normally to some point but then only the text box gets smaller and the buttons remain unproportionally large. So is there a way to tell my app not to scale any sizes and just let everything be exactly the same pixel size as it would be on a normal dpi (despite the fact that my app will look small on higher resolutions)?
There is no way to prevent the proper scaling from being applied using wxWidgets API and I don't think this is going to change because it just doesn't seem to make any sense.
However rebuilding wxWidgets with wxHAVE_DPI_INDEPENDENT_PIXELS defined should trick the library into thinking that the underlying graphical toolkit already scales the pixel values and so prevent it from doing it on its own. I've never tested this but, AFAICS, this should result in what you want.
Nevertheless let me reiterate that what you want is totally wrong and the real fix for this problem is to explain it to whoever decided to do it.
We've now got 4-resolutions to support and my app needs at least 6 full-screen background images to be pretty. Don't want to break the bank on megabytes of images.
I see guides online about loading PDFs as images and custom SVG libraries but no discussion of prectically.
Here's the question: considering rendering speed and file size, what is the bet way to use vector images in iOS? And in addition, are there any practical caching or other considerations one should make in real world app development?
Something to consider for simple graphics, such as the type of thing used for backgrounds, etc., is just to render them at runtime using CG.
For example, in one of our apps, instead of including the typical repeating background tile image in all the required resolutions, we instead draw it once into a CGPatternRef, then convert it to a UIColor, at which point things become simple.
We still use graphic files for complex things, but for anything that's simple in nature, we just render it at runtime and cache the result, so we get resolution independence without gobs of image files. It's also made maintenance quite a bit easier.