Hi people.
I have a Samsung Galaxy (with AMOLED but I don't think it's got the Pentile display system) and (since today) an LG P500 Optimus One.
The Galaxy is running a GAOSP nightly (which is based on CyanogenMod), and the P500 is running the default software.
I can't currently make screenshots (if I know how to do this, I'll update this post), but while I'm very happy with the P500's performance next to the anemic, memory starved Galaxy (GAOSP optimizations are good but insufficient to remedy the lack of memory), font rendering on the P500 is not good (it reminds me of linux 5 years ago: there seems to be some anti aliasing going on, but I'm quite sure there's no subpixel smoothing going on.
Since the two displays have the exact same resolution, I'd expect fonts (at least in the UI itself) to be rendered similarly but they obviously aren't.
Can someone enlighten me as to what's needed to encourage Android to enable subpixel smoothing on fonts? Is it in the kernel (and out of my immediate reach), or in a config file somewhere I can edit (if I get root on this nice little phone)?
Nobody?
I've read a bit about fonts in Android, and it seems Android uses Freetype, but I haven't found out how Freetype can be tweaked (config files, copy/paste a compiled file from another device, or really needs to be compiled in from scratch)
Related
Hello,
I've spent the last month trying desperately to find a free 2D (or 3D, but not required) graphics API I can use for high performance games on Windows Mobile. I initially set about trying to find a managed API to use, but now I've broadened my search to include any API (that I can call from C++ or .NET), and I'm still struggling to find anything.
The options seem to be:
- GDI: not nearly fast enough for high performance games
- DirectDraw: probably OK, but doesn't seem possible to use this on my HTC Touch Pro 2 due to memory problems (see http://blogs.msdn.com/windowsmobile/archive/2009/04/17/twisted-pixels-3-memory-mysteries.aspx -- I've got the same problem and have not yet found any way to work around this)
- Direct3D: no hardware driver on my Touch Pro 2, this renders about 0.2 frames per second in the samples, which is not good enough
- OpenGL: I've tried and tried, and can't get any samples working for this. The closest I've found is the tutorials here: http://www.zeuscmd.com/tutorials/opengles/index.php, but these all fail with an error, "Unable to create OpenGL|ES context" as soon as I run them (or alternatively using the "Ug" version, I get no window appearing at all).
Does anyone have any suggestions as to how I can progress from here? I really want to write some Windows Mobile games, but I can't even get started. :-(
Thanks,
Adam.
For 'better' graphics performance have a look at the 2D/3D Driver Development for MSM720X devices!
After installation of this driver pack try my OpenGL test app (source also available) found in my sig! Installing this driver pack will increase d3d performance, too!
Hi heliosdev,
Many thanks for posting the sourcecode for your OpenGL test -- I have that compiling very nicely here and producing very promising results too. I think this may finally be the answer I've been looking for.
Do you have any idea how much of a performance hit using PInvoke to interact with OGLES is likely to be? I don't know whether PInvoke is slow to use or not, but it strikes me that it may be slower use it hundreds of times per frame compared to coding directly in C++ and not needing to PInvoke at all..?
Thanks again,
Adam.
For comparison NuShrike implemented torus test in C++. As you can see the difference is 'minimal' even NuShrike optimized it using vertex buffer objects (I'm using standard vertex arrays and just triangles, i.e. no triangle strips).
I have now researched the various 'ROMs' (actually firmware), and have narrowed the field to four. I'd like input on these. Priorities are (in order):
1. Complete Stability. I've run TomTom on WM5 for 6 years, and outside of TomTom it's a real mess. WM is so buggy I can't use it confidently for anything other than nav.
2. Good Battery. I have a friend who just got an Evo, and he says battery lasts only ~3 hours. I'm sure that's because of the large display, but also I read that several ROMs and apps really sacrifice battery on the N1. One screen I want to have dedicated to some sort of CPU/Mem/Storage monitor, so I can easily check it.
3. Lots Of Cool Features. It seems that video at 720p might be problematic as I gather it's really 3Mp upsampled, and/or it disables the still camera/flash somehow? Kernel optimizations are nice, although "deodexing" is not defined -anywhere-. I'm unlikely to stray beyond the UI built into the ROM, as it could introduce instabilities.
a. CM6 - The Big Kahouna. This ROM will likely be supported for a long time and is likely to integrate the newest kool features over time.
b. MoDaCo - Its thing seems to be stability, although a feature-by-feature comparison with CM6 leaves me confused, much less comparative usability is impossible to determine. Kitchen allows preclusion of G**gle apps.
c. LeoFroYo - The guy seems to know what he's doing, so under consideration. Comes with G**gle apps tho.
d. Kang-o-rama - an innovator whose improvements have been co-opted by others.
e. RoDrIgUeZsTyLe - I like it, but it is clearly very ill given the thread comments. Rejected.
Really? Nobody knows anything about this?
it depends on which phone u have bro, u didnt even specify that
Hello there,
I'm interested in developing image processing software for android devices. So far I got OpenCV and a simple example app running on my HTC Desire. It finds ellipses in realtime in a camera preview surface. The speed is OK (15 fps) and I expected the performance on the eeepad Transformer to be even faster. But the opposite is the case. The native (c++ implementation) camera preview that worked well on the Desire ist horribly slow on the transformer.
For me it's seems like the app has no full priority. Is there a way to give an app exclusive priority so it can use more CPU power? Are there some hidden performace switches on honeycomb I have to activate in order to get this app going faster?
thanks in advance for every answer or even hints to other forums.
SirHoop
I check the debug log of the native processor, apperently it processes the images with up to 30 fps. Unfortunately that is not the framerate I see on my display. This let's me conclude that there is a fundamental problem with the CameraPreview class on the transformer.
Apparently this is an OpenGL ES problem. The NativeCameraPreviewer of OpenCV uses a GLSurfaceView to draw the modified camera image. I use an additional GLSurfaceView to render some 3D content on top of that preview surface. So, 2 GLSurfaceViews are active and somehow that causes problems on either this specific device or android 3.0. On an HTC Desire running 2.2 this problem did not arise.
That's all I got, unfortunately I could not fix it so far. Just deactivating the second GLSurface made the camera preview smooth.
Hello,
Well, the title says it all.
I've been operating a Moto G for 2 weeks and half now (KitKat 4.4.4); migrated from a venerable yet robust BB Bold 9900.
The experience, overall, has been positive, though Android's multitasking/memory management seems INFERIOR to the one implemented in that old 9900.
It got really pissed off after the browser dumped my posting form... c'mon, just for switching tabs/apps to check a dictionary? FFS!!! (browser pages reload from wherever the hell data is “stored” -cough, cough-, SLOWER than a snail...) ¡FAILURE!
Well, back on topic.
I've observed my Android phone default battery voltage thresholds are 3'4 and 4'2 V. I'd like to be able to, at least, tweak these values. Software managed (even profiled) on-the-fly adjustment of the full load voltage would be ideal.
The “low-battery” popup window warning is a cancer and deserves to be eradicated.
Tweaking the power profiles to allow the phone to use more power in the benefit of a more desktop computer-like experience would also be of interest to me, at least when the phone is plugged, of course!
My phone is unrooted yet, but I'm planning on doing it after my Lollipop OTA upgrade, which looks inminent.
Thank you in advance for your help.
Cheers.
Ultimate solution for browsing the "desktop" internet on mobile (dev help request)
Background:
Moto G 2013 running optimized rooted Lollipop 5.1.
Related tweaks:
ro.sf.lcd_density=240 set in build.prop (apparent screen size: 6"). UI Tuner installed.
On Chrome Dev 56.0.2900.3
data/local/chrome-command-line contents:
chrome --user-agent="Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2900.3 Safari/537.36"
Well my dears, lets see if I can wake up a bit of freakin' interest here :fingers-crossed:. As you may know and probably suffer, certain websites serve their content selectively by requesting the client's browser certain specific information, namely screen resolution and pixel density (dpi). In this way, sites can determine the actual screen size of the client and ta-da!: you receive a freaking zoomed-in, crippled pile of sh1tepage. Sorry if this sounds gross, grossman. :silly:
The classic solution I already am using, as you already know. Main problem is that, as a mobile user, I have to deal with how the System UI gets impacted by my dpi/resolution changes. What this chiefly means is that, as a user of a device deprived of physical navigation buttons/bar, if I reduce too much my dpi, at a certain point the system UI gladly decides that it is 0K to misuse one of the most precious resources in this age of stupid, fashionable 16:9 screens (sorry) by relocating the navigation bar "down there", taking up screen width and also completely pissing off (even more) the useable screen aspect ratio. Reducing the dpi actually makes using the device much better in general, as some of you may already know. However...
In order to ride the real thing on the browser, seems to me we need to address this problem, an this is where my developer help request comes in. Chrome, and other browsers, serve our device's dpi setting at the will of requesting sites, is this right? Thus, I've thought some sort of small application/service could be made in order for it to fake our dpi setting to the whatever thing which requests it, and maybe also fake our actual resolution (sorry, already tried the per app settings in UI Tuner: doesn't works without screwing up the whole shebang -system UI- :silly.
Does all of this sounds right? Of course, with regards to how certain system stuff works I am making certain presumptions which may be wrong, yet I'm sure something nice can be done.
I'd gladly like to hear from you, comrades. Android FTW! :victory:
Cheers