|
Replies:
1
-
Last Post:
Jan 3, 2009 12:26 PM
by: Shai Almog
|
|
|
|
|
|
|
getKeyStates [Was: Re: Canvas in lwuit]
Posted:
Jan 3, 2009 12:57 AM
|
|
|
On Fri, Jan 2, 2009 at 3:32 PM, Shai Almog <Shai.Almog@sun.com> wrote:
> This approach is not what I would recommend.
> First the compile error is due to the new porting layer which no longer
> returns MIDP Graphics from the getGraphics method. It returns an object for
> portability which as a stop measure you can downcast to MIDP Graphics.
> Obviously this will not work on the BlackBerry Port, CDC port etc.
> The approach of modifying GameCanvas seems unnecessary. You can derive from
> and install your own LWUITImplementation's as is done by both the BlackBerry
> port and the Canvas port within SVN and LWUIT incubator.
> Also from within the LWUIT package you can call
> Display.getImplementation().getNativeGraphics(); which is a public method
> (only you don't have public access to the current implementation class).
I certainly understand that changes of this nature have important
residual effects and should not be made capriciously. I'll have a
look at the incubator projects too. I must disclose, however, the
real reason I wanted this change - so that I can call
canvas.getKeyStates(), is there an alternative? My application is not
event driven (it polls the keystate in a real-time fashion).
Basically, my app starts a thread whose pseudo-code resembles:
BEGIN
create image
get image graphics
while (true) {
getKeystates
bind 3d graphics to image graphics
render
lwuit_form.setBgImage to image
lwuit_form.repaint
}
END
Input state is updated every time through the loop. Now, having
integrated LWUIT... I present the 2d gui using it in an event driven
manner and use polling on the m3g side of things (per frame).
Because of this I wasn't sure how/if I could incorporate LWUIT easily
and quickly. The changes simply emerged in my path of least
resistance. With LWUIT, if traditional 2d interaction is required...
I construct a form and show it, otherwise I show an empty form and
only the m3g scene is changed (and, again, updated based on keystate).
I glanced at the dev guide and considered using M3G.Callback perhaps
somehow w/ GlassPane, idk... nothing looked obvious. But after a bit
of playing I noticed that by changing only 3 lines in LWUIT, I could
integrate it very quickly. I suppose safety took a back seat to
desire. I briefly considered using a factory to create a second
canvas, but getKeyState fails if the canvas isn't being displayed
(requiring more changes to my app).
Hopefully I've painted a reasonable picture of my situation. I
changed GameCanvasImplementation.canvas to protected, made
lwuit.Image.getImage public, and lwuit.Graphics.getGraphics public
then I inherit from GameCanvasImplementation instead of
lcdui.game.GameCanvas. Ultimately, the changes to my code remained
negligible (this was/is important to me). I may not technically need
the two public getter methods either but it minimized changes to my
app.
So far I haven't experienced problems. Perhaps you're warning me that
large pitfalls exist? *GULP*
I guess my more immediate concern is that LWUIT is constantly
creating/freeing objects in the main loop and I'd prefer static
allocations to prolong invokation of the gc as long as possible. It's
especially a concern when the empty form is shown (AFAIK memory
doesn't need to be newed/freed in this case, but it is).
lwuit.geom.Dimension, lwuit.geom.Rectangle, and VectorEnumerator are
wasted on a per frame basis... I don't see a reason why (the form is
empty and not changing).
Granted, LWUIT is more resource intensive than my previous primitive
keystate driven 2d ui *but* it's prettier, has a broader set of
widgets/goodies and generally fancier - good things IMHO. I'll have
to look and see what I can do about the memory leaks.
If I'm seriously shooting myself in the foot (or anyone just knows of
a better way) I would love feedback. Again, I greatly appreciate all
the help!
Thanks 1e6,
Dino
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net
|
|
|
|
|
|
|
Re: getKeyStates [Was: Re: Canvas in lwuit]
Posted:
Jan 3, 2009 12:26 PM
in response to: signal3
|
|
|
|
|
To call getKeyStates() you can use the MIDP Display class to get the
current Displayable or follow a similar approach of building your own
implementation class. Both approaches would limit your portability to
other LWUIT platforms though (such as the BlackBerry).
The main problem with drawing directly on the canvas without going
through LWUIT is in collision with LWUIT's own drawing. Since LWUIT
uses the GameCanvas (which is something that currently we aren't
changing but we might choose to) the flushGraphics call could cause a
problem for you in some cases. Since you draw with a native graphics
which expects flushing to occur when you finish.
You might also have failures on the device itself since LWUIT calls
flushGraphics/drawing from the LWUIT thread and you might choose to
use your own thread for drawing... So generally these aren't
supported and are the exact reason why we offer the M3G class.
The use case for the key state support is interesting, we don't
expose it since its not very cross platform and would be problematic
in that sense. However, if you implement this safely it should pose
no problem beyond limiting portability.
> On Fri, Jan 2, 2009 at 3:32 PM, Shai Almog <Shai.Almog@sun.com> wrote:
>> This approach is not what I would recommend.
>> First the compile error is due to the new porting layer which no
>> longer
>> returns MIDP Graphics from the getGraphics method. It returns an
>> object for
>> portability which as a stop measure you can downcast to MIDP
>> Graphics.
>> Obviously this will not work on the BlackBerry Port, CDC port etc.
>> The approach of modifying GameCanvas seems unnecessary. You can
>> derive from
>> and install your own LWUITImplementation's as is done by both the
>> BlackBerry
>> port and the Canvas port within SVN and LWUIT incubator.
>> Also from within the LWUIT package you can call
>> Display.getImplementation().getNativeGraphics(); which is a public
>> method
>> (only you don't have public access to the current implementation
>> class).
>
> I certainly understand that changes of this nature have important
> residual effects and should not be made capriciously. I'll have a
> look at the incubator projects too. I must disclose, however, the
> real reason I wanted this change - so that I can call
> canvas.getKeyStates(), is there an alternative? My application is not
> event driven (it polls the keystate in a real-time fashion).
> Basically, my app starts a thread whose pseudo-code resembles:
>
> BEGIN
> create image
> get image graphics
> while (true) {
> getKeystates
> bind 3d graphics to image graphics
> render
> lwuit_form.setBgImage to image
> lwuit_form.repaint
> }
> END
>
> Input state is updated every time through the loop. Now, having
> integrated LWUIT... I present the 2d gui using it in an event driven
> manner and use polling on the m3g side of things (per frame).
>
> Because of this I wasn't sure how/if I could incorporate LWUIT easily
> and quickly. The changes simply emerged in my path of least
> resistance. With LWUIT, if traditional 2d interaction is required...
> I construct a form and show it, otherwise I show an empty form and
> only the m3g scene is changed (and, again, updated based on keystate).
>
> I glanced at the dev guide and considered using M3G.Callback perhaps
> somehow w/ GlassPane, idk... nothing looked obvious. But after a bit
> of playing I noticed that by changing only 3 lines in LWUIT, I could
> integrate it very quickly. I suppose safety took a back seat to
> desire. I briefly considered using a factory to create a second
> canvas, but getKeyState fails if the canvas isn't being displayed
> (requiring more changes to my app).
>
> Hopefully I've painted a reasonable picture of my situation. I
> changed GameCanvasImplementation.canvas to protected, made
> lwuit.Image.getImage public, and lwuit.Graphics.getGraphics public
> then I inherit from GameCanvasImplementation instead of
> lcdui.game.GameCanvas. Ultimately, the changes to my code remained
> negligible (this was/is important to me). I may not technically need
> the two public getter methods either but it minimized changes to my
> app.
>
> So far I haven't experienced problems. Perhaps you're warning me that
> large pitfalls exist? *GULP*
>
> I guess my more immediate concern is that LWUIT is constantly
> creating/freeing objects in the main loop and I'd prefer static
> allocations to prolong invokation of the gc as long as possible. It's
> especially a concern when the empty form is shown (AFAIK memory
> doesn't need to be newed/freed in this case, but it is).
> lwuit.geom.Dimension, lwuit.geom.Rectangle, and VectorEnumerator are
> wasted on a per frame basis... I don't see a reason why (the form is
> empty and not changing).
>
> Granted, LWUIT is more resource intensive than my previous primitive
> keystate driven 2d ui *but* it's prettier, has a broader set of
> widgets/goodies and generally fancier - good things IMHO. I'll have
> to look and see what I can do about the memory leaks.
>
> If I'm seriously shooting myself in the foot (or anyone just knows of
> a better way) I would love feedback. Again, I greatly appreciate all
> the help!
>
> Thanks 1e6,
> Dino
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
Shai Almog
http://lwuit.blogspot.com/
[att1.html]
|
|
|
|
|
java.net RSS
