When i maximize an air window that has no chrome (no system chrome, no flex chrome but i think it's the same even if only flex chrome is used) a few pixels on all sides go offscreen.
Anyone has a solution for this or knows why it happens?
It's actually easiest to set the air window to the size of the monitor, then set your custom UI to the size of the monitor minus a few pixels. That's the only workaround that I've come up with.
The only downside to this approach may be a small rendering performance loss, since the AIR window has to take alpha transparent pictures of everything behind the window, but this likely so minimal that it won't make a difference (I invite someone to benchmark this).
Related
We have a Delphi 7 program running on Windows 7 Professional SP1, developed approximately 10 years ago. On the current system, it became unusable as some form elements have incorrect size so the text they contain doesn't fit there or the graph overflows the bottom of the window:
Picture 1: Table rows have incorrect size (or the text is bigger than it should be)
Picture 2: There is a graph in the window but the bottom part of the graph isn't visible. And there are no scrollbars...
We have no source code nor we do we have contact with the people who developed the software. We think the software was built in Delphi 7 because it uses several xxxx70.bpl libraries.
We tried to change resolution of the screen and change compatibility mode used to run the program with no luck.
Is there anything we can try?
Your program is not DPI aware, and you are running with font scaling settings that mean the application is asked to scale. The application font is scaled automatically but your Delphi application does not adapt.
I can see some options for you:
Run your machine with 100% font scaling.
Run your machine with >125% font scaling. Then DPI virtualization will kick in which should fix the issue. Although the app may appear fuzzy as it will suffer aliasing when scaled.
Try to find a compat setting that forces DPI virtualization. Don't know if such a thing exists.
Edit the .dfm resources in the executable to set the Scaled property to true. This would require a resource editor that understands Delphi. For instance XN resource editor. I've no idea whether or not this will work. If it does work, each form will re-scale themselves according to the font scaling.
Update
Forcing DPI virtualization won't help, on second thoughts. The system will tell your app that the font scaling is 125% and scale from there. But your app won't even handle 125% scaling correctly it seems. So you have little option other than to disable all font scaling or perhaps try with the Scaled property.
If you make a simple website with the code:
<div style='background-color: rgba(0,0,0,.05);width:50px;height:50px'></div>
and view it on various devices, you'll see very different colors.
On my iPhone and iPad, it looks white but on my MacBook you can see a definite light grey that looks close to #fafafa; I haven't tested thoroughly on other devices but I think that Android Chrome will sometimes display a third in between color.
This isn't an issue of different screen color capacities, because the iPad is definitely capable of displaying #fafafa.
So what's the story and is there any way to fix it?
rgba(0,0,0,.05) is an incredibly light color. A 5% tint is not visible on many lower end LCDs - especially 6bit panels. Personally, when I use RGBA I only tweak by 10% increments. Also, you will notice that #fafafa and rgba(0,0,0,.05) don't display the same because they aren't the same. #f2f2f2 is rgba(0,0,0,.05) (at least in Photoshop.)
You also have variances between the type of RGB. Devices also adapt differently based on lighting conditions - and they don't adapt the same way. There's also different screen types like AMOLED
From my experience that normally happens because of the contrast on the different screens and brightness settings. My suggestion is play with those.
Also check this for browser compatibility but those you mentioned should be ok:
http://css-tricks.com/rgba-browser-support/
I've been experimenting with createjs to convert some flash as3 animations to HTML5. everything works fine in desktop browsers, but on an i-pad the animation are considerably slower. Where there are complex vector objects they are so slow as to be unusable. I can speed things up by caching the objects, but the quality of the resulting graphics is poor. Are there any solutions to this problem?
Thanks in advance
Pete
take a look on canvas size. after a centain size the mobile vídeo boards cannot accelerate the graphics like pc does.
Tip #4. Watch The Size of Your Canvas
Obviously, the larger the canvas the more costly the drawing
operation, but if you’re targeting mobile devices, there are some size
limits you must keep in mind.
From Safari Web Content Guide:
The maximum size for a canvas element is 3 megapixels for devices with
less than 256 MB RAM and 5 megapixels for devices with greater or
equal than 256 MB RAM
So if you want to support Apple’s older hardware, the size of your
canvas cannot exceed 2048×1464.
But that’s not all! Even with smaller sizes, you have to keep your
canvas’s aspect ratio between ~3/4 and ~4/3. If you step outside those
boundaries, webkit seems to switch to a totally different rendering
mode splitting the canvas into multiple fixed-size areas and rendering
them separately with a noticeable delay between them.
There doesn’t seem to be any documentation on this but I have
confirmed this happens on both Chrome and Safari on iOS versions 6.0.1
and 5.1.1.
source http://blog.toggl.com/2013/05/6-performance-tips-for-html-canvas-and-createjs/
On a desktop, I can get this button to display nicely (in Firefox anyway, I only need it to work on very few browsers) and it scales appropriately.
http://www.coflash.com/svg/
However, on an iPad3, the icon changes size and seems to be cut off. I can't figure out why this is happening. I'm guessing it's because of the pixel density/higher DPI but I don't even know where to begin on getting around it.
Does anyone have any experience with this?
I've been working on an iPad app that has gone through fairly extensive testing on the iPad 2. I recently obtained a "New iPad" (iPad 3), and the app feels significantly slower. Animations / scolling behaviors that were silky smooth in the iPad 2 now feel extremely stuttery on the new iPad.
I do a lot of the standard UI performance tips: using shadowPaths, drawing UITableViewCells using CoreGraphics, rasterizing views that don't change often / don't need to animate.
Are there any pitfalls I should watch be watching out for in transitioning my app to the iPad 3?
Update
I swore that I tried this before but removing rounded corners from my UIViews views ended up speeding the app significantly. clipToBounds also seems to be a significant performance hit (although strangely... setting a view's layer's maskToBounds seems to be okay, which makes no sense to me). Some combination of this and other tweaks seems to have resolved the issue.
Once I do a second visual pass over the app, I'll figure out a way to reimplement rounded corners in a more performant way.
4x the pixels, only 2x the fill rate. The maths says it all.
I think that the biggest thing to watch out for is copies of graphics from system memory to the video card since they are 4X larger than previous iPad graphics with about the same CPU power as the iPad 2.
Maybe it's due to upscaling by iOS? After all it has to calculate a higher res version of everything before showing to screen. Since some things on the screen are hi-res already (font and default ui elements) it has to scale every other element individually.
Have you tried just scaling the images yourself and adding them as retina images to your project?
Good luck.