I'm creating an application with large bitmaps in a scrolling list.
I'm on a 1080p screen and the bitmaps are about 1080x1080 pixels each. All
drawing is done directly to canvas in a custom View, and all of the bitmaps
are loaded from resources into memory before doing any scrolling (well, at
On Tuesday, November 20, 2012 4:44:45 PM UTC+1, Romain Guy (Google) wrote:
No you cannot disable DisplayLists. They are required by the UI toolkit.
2MB if display lists seems excessive. Apps like Launcher use in the order
of 15 kB.
On Nov 20, 2012 7:22 AM, hanni han...@gmail.com javascript: wrote
I've created a bunch of custom views that draw themselves really fast,
especially with HW acceleration enabled.
I have several of these views in my application, spread out over many
panes. I'm trying to keep as much as possible in memory to avoid reloading
data when swiping between panes.
My
will
likely run into other issues.
On Sat, Apr 7, 2012 at 4:06 AM, hanni hann...@gmail.com wrote:
Hi all,
I'm making an app that has standard Android Views on OpenGL ES
textures, allowing them to be rendered on any 3D mesh. I have
everything working, like touch and correct View
Hi all,
I'm making an app that has standard Android Views on OpenGL ES
textures, allowing them to be rendered on any 3D mesh. I have
everything working, like touch and correct View invalidates. The way
I'm doing it is putting all the Android Views that are supposed to
rendered to textures in my
Hi,
In my application, sometimes I need to do certain things after the
current screen has been rendered, and displayed to the user.
I'm using the MessageHandler.sendEmptyMessageDelayed() strategy to
create a render-loop, invalidating the screen on each message. Then
all rendering is done in the
Hi!
I believe this problem is due to a issueI have been following closely,
issue #319. In my application, after using the touch device, the first
DPAD keypress is consumed completely and there is nothing to do about
it. The bug should be fixed now and the fix should be included in the
next
=4colspec=I...
thanks,
Anil
On Mar 27, 2:54 am, hanni [EMAIL PROTECTED] wrote:
No, I can't think of any other way to work around this behaviour.
Well, maybe if there is any way of detecting that the dpad tried to
change the focus, and in which direction. Then I could try to
interpret
Hi, my application makes heavy use of semi-transparent .png's for
interesting graphics. I'm used to this, developing J2ME applications.
The alpha blending algorithm in Android, however, seems to be less
than adequate. Everything that is semi-transparent is restricted to
very few shades of color,
lose all its color and become black.
So if the image has a pixel with a full red colour of 0x, it
stays red, but if it is a semi-transparent red color such as
0x7FFF, it is returned as the color 0x7F00, with both the
getPixels() and the getPixel() methods.
On 5 Apr, 18:02, hanni
is finished? Perhaps at
the same time as the double buffer swapping takes place, or such? If
it doesn't mean a big performance hit, of course.
Best Regards,
Daniel
On 5 Apr, 19:05, hanni [EMAIL PROTECTED] wrote:
Oh, I just noticed that if I try to do it the other way, that is,
extract the pixels
11 matches
Mail list logo
