More thoughts about wxAndroid
Vadim Zeitlin
I spent a couple of hours yesterday reading Android documentation and
playing with the samples and it looks like it ought to be possible to write
a wxUniversal port working on Android. At least the native activity sample
in the NDK shows how we can react to the events (it shows it only for
sensor input but handling keyboard and touch events should be similar) and
draw on screen using only native code.
The problem is that the only way to draw something is to use OpenGL (well,
we can also have raw access to Java bitmaps but it's not really clear what
can we do with them). So to have the existing wxUniversal code work we need
to either provide an implementation of all the GDI classes using OpenGL
which is going to be a lot of work and at least some things are likely to
be impossible to implement at all. Or we could provide a wxUniv renderer
using OpenGL instead of wx GDI classes. This should be simpler but less
generally useful as you wouldn't be able to draw in your own code using
wxDC. OTOH writing a new renderer would allow to get an appearance closer
to the standard Android one instead of having ugly and out of place
Win95-like widgets. Also, having OpenGL-based implementation of wx GDI
classes (or perhaps wxGraphicsContext, as we already have wxGCDC?) could be
useful not only under Android.
Anyhow, I think there are 2 mostly independent parts:
(1) Implement wxApp and wxEventLoop using native activity, i.e. event
handling and general application startup/shutdown logic.
(2) Implement drawing in some way.
To return to the GSoC aspect of things, I think (1) is too difficult and
risky to give to a student as while it looks like it ought to be possible,
I might be missing some problems with it. OTOH (2) is "just" a lot of work
but does seem to be doable, so this could be proposed as a GSoC project.
The trouble is that if (1) turns out to be impossible, then (2) would be a
waste of time and energy (unless it could be also reused by e.g. wxiOS?) so
ideal would be to try to do (1) a.s.a.p. I definitely won't have time for
it in the GSoC projects acceptance time frame however...
Regards,
VZ
Eric Jensen
at least for MSW an OpenGL based renderer would be very useful,
because GDI+ is not hardware-accelerated. So right now, you can either
have hardware-acceleration with GDI or proper transparency and
subpixel accuracy with GDI+, but not both.
For my own purposes i had planed to create a wxDC based implementation
in the near future, but that would have supported only the few drawing
operations i actually need for my project.
I also took a look at wxGraphicsContext to see if i could turn it
into a nice contribution to wxWidgets, but the effort to create a
wxGraphicsContext implementation seemed to be several factors higher,
so i discarded that idea. (Mainly because there is no real
documentation, so i checked the Cairo renderer, but unfortunately i
didn't understand several of the implementation details).
I think Stefan would be the perfect person to do this, but
unfortunately he seems to be totally overloaded with work already :(
Regards,
Eric
Julian Smart
Interesting analysis, thank you.
On 27/02/2012 15:06, Vadim Zeitlin wrote:
> Anyhow, I think there are 2 mostly independent parts:
>
> (1) Implement wxApp and wxEventLoop using native activity, i.e. event
> handling and general application startup/shutdown logic.
> (2) Implement drawing in some way.
>
> To return to the GSoC aspect of things, I think (1) is too difficult and
> risky to give to a student as while it looks like it ought to be possible,
> I might be missing some problems with it. OTOH (2) is "just" a lot of work
> but does seem to be doable, so this could be proposed as a GSoC project.
> The trouble is that if (1) turns out to be impossible, then (2) would be a
> waste of time and energy (unless it could be also reused by e.g. wxiOS?) so
> ideal would be to try to do (1) a.s.a.p. I definitely won't have time for
> it in the GSoC projects acceptance time frame however...
Presumably Qt and NDK-based games have to do something similar to
wxApp/wxEventLoop on Android, though it might involve interfacing with Java.
The drawing conundrum - I would imagine that most applications would
have at least some custom drawing code, so to me the most useful
approach would be to write wxDC/wxGCDC in OpenGL. The point about a
renderer-only approach: since it's not a native port I don't think many
people would be expecting this type of application to look completely
native; we're just not going to manage that with a wxUniversal port.
Besides, the wxDC approach still allows us to write a better theme at
some point. So I think it's more important that a large subset of
wxWidgets applications could run, and IMO losing the ability to draw
custom code would make the port of limited interest. Many widgets still
rely on custom drawing, e.g. AUI. Once we demonstrated a wxAndroid
application with a Win95-like UI, I'm pretty sure there would be
motivation to improve the theme.
I agree that it could be hard to attract talent to tackle the event
loop, so I guess we're kind of stuck unless someone comes forward... for
the right person, implementing some wxDC API would have beeen quite a
nice challenge but we might need to wait until next GSoC when we might
have some basics in place.
Regards,
Julian
>
> Regards,
> VZ
--
Julian Smart, Anthemion Software Ltd.
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
Ebook creation: www.jutoh.com
wxWidgets RAD: www.dialogblocks.com
Vadim Zeitlin
EJ> at least for MSW an OpenGL based renderer would be very useful,
EJ> because GDI+ is not hardware-accelerated.
Are you sure about this? GDI+ uses GDI internally so if GDI is (at least
somewhat) hardware-accelerated, why isn't GDI+?
EJ> For my own purposes i had planed to create a wxDC based implementation
EJ> in the near future, but that would have supported only the few drawing
EJ> operations i actually need for my project.
Well, having at least something basic would be much better than not having
anything at all.
EJ> I also took a look at wxGraphicsContext to see if i could turn it
EJ> into a nice contribution to wxWidgets, but the effort to create a
EJ> wxGraphicsContext implementation seemed to be several factors higher,
I think the main problem is that you need to implement support for paths
and I'm not sure if OpenGL has any native equivalent for this, so this
risks being difficult.
Still, considering that native drawing API under GTK+ and OS X is now
wxGraphicsContext (and not wxDC) it would be clearly much better
strategically to provide its implementation for Android, rather than just
the wxDC stuff.
Regards,
VZ
Vadim Zeitlin
JS> On 27/02/2012 15:06, Vadim Zeitlin wrote:
JS> > Anyhow, I think there are 2 mostly independent parts:
JS> >
JS> > (1) Implement wxApp and wxEventLoop using native activity, i.e. event
JS> > handling and general application startup/shutdown logic.
JS> > (2) Implement drawing in some way.
JS> >
JS> > To return to the GSoC aspect of things, I think (1) is too difficult and
JS> > risky to give to a student as while it looks like it ought to be possible,
JS> > I might be missing some problems with it. OTOH (2) is "just" a lot of work
JS> > but does seem to be doable, so this could be proposed as a GSoC project.
JS> > The trouble is that if (1) turns out to be impossible, then (2) would be a
JS> > waste of time and energy (unless it could be also reused by e.g. wxiOS?) so
JS> > ideal would be to try to do (1) a.s.a.p. I definitely won't have time for
JS> > it in the GSoC projects acceptance time frame however...
JS> Presumably Qt and NDK-based games have to do something similar to
JS> wxApp/wxEventLoop on Android,
Yes, NDK-based games do exactly this AFAIK.
JS> though it might involve interfacing with Java.
No, you don't need any Java code starting from Android 2.3 (platform 9)
and I think we shouldn't have any troubles with setting this is a minimal
requirement.
JS> I agree that it could be hard to attract talent to tackle the event
JS> loop, so I guess we're kind of stuck unless someone comes forward... for
JS> the right person, implementing some wxDC API would have beeen quite a
JS> nice challenge but we might need to wait until next GSoC when we might
JS> have some basics in place.
Yes, this is more or less my conclusion too.
Regards,
VZ
Peter Most
> Presumably Qt and NDK-based games have to do something similar to
> wxApp/wxEventLoop on Android, though it might involve interfacing with Java.
KDE support?
Regards Peter
Eric Jensen
Monday, February 27, 2012, 5:13:24 PM, you wrote:
VZ> On Mon, 27 Feb 2012 16:49:43 +0100 Eric Jensen <m...@j-dev.de> wrote:
EJ>> at least for MSW an OpenGL based renderer would be very useful,
EJ>> because GDI+ is not hardware-accelerated.
VZ> Are you sure about this? GDI+ uses GDI internally so if GDI is (at least
VZ> somewhat) hardware-accelerated, why isn't GDI+?
I have no valid source of information, but it's based on experience ;)
I made a little benchmark a while ago:
Rendering 500.000 solid-colored rectangles (64x64 pixel)
wxDC: 1.26 secs
wxGraphicsContext: 55.94 secs
Rendering 500.000 bitmaps (toucan.png non-scaled):
wxDC: 23.09 secs
wxGraphicsContext: 115.22 secs
I'd say GDI+ is significantly slower.
Tested on XP.
Regards,
Eric
Vadim Zeitlin
PM> > Presumably Qt and NDK-based games have to do something similar to
PM> > wxApp/wxEventLoop on Android, though it might involve interfacing with Java.
PM>
PM> Could it be worthwhile to advance wxQt further
Personally I remain of the opinion that wxQt is not very interesting
strategically for us and so am not really motivated in working on it. But
if you or anybody else are interested in continuing working on it, why not?
PM> so we get Android and KDE support?
What is the state of wxQt under Android? At the very least, if it works
(well) there, it would be an inspiration for us...
Regards,
VZ
Peter Most
> PM> so we get Android and KDE support?
>
> What is the state of wxQt under Android? At the very least, if it works
> (well) there, it would be an inspiration for us...
>
youself:
http://labs.qt.nokia.com/2011/02/28/necessitas/
http://sourceforge.net/p/necessitas/home/necessitas/
http://developer.qt.nokia.com/wiki/How_to_Create_and_Run_Qt_Application_for_Android
...
Regards Peter
Julian Smart
That's definitely a valid alternative approach... if the wx + Qt combo
doesn't stretch the resources of mobile platforms too much. I just
wonder if it'll prove too hard to fight issues in wxWidgets and Qt and
Android simultaneously! A lot to juggle... but it still might be easier
than writing to the Android API ourselves.
Regards,
Julian
>
> Regards Peter
Vadim Zeitlin
EJ> VZ> Are you sure about this? GDI+ uses GDI internally so if GDI is (at least
EJ> VZ> somewhat) hardware-accelerated, why isn't GDI+?
EJ> I have no valid source of information, but it's based on experience ;)
EJ>
EJ> I made a little benchmark a while ago:
EJ>
EJ> Rendering 500.000 solid-colored rectangles (64x64 pixel)
EJ> wxDC: 1.26 secs
EJ> wxGraphicsContext: 55.94 secs
EJ>
EJ> Rendering 500.000 bitmaps (toucan.png non-scaled):
EJ> wxDC: 23.09 secs
EJ> wxGraphicsContext: 115.22 secs
EJ>
EJ> I'd say GDI+ is significantly slower.
EJ>
EJ> Tested on XP.
I think it could be useful to retest under Vista/7, I'd expect GDI+ to be
better there. In fact, if you could extend tests/benchmarks/graphics.cpp
with your tests, this would be useful as it would allow us to compare wxDC
and wxGraphicsContext performance on all platforms.
Regards,
VZ
Krishna
On Mon, Feb 27, 2012 at 8:36 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> (2) Implement drawing in some way.
>
Instead of implementing wxGCDC and friends from scratch wouldn't it be
simpler to wrap an existing library? skia, cairo, agg come to mind.
For text, pango+freetype seems to be the easiest route. There is also
a Quartz2D implementation from the Cocotron project although that is a
software-only implementation.
What is the status of wxDirectFB? If [1] is to be believed, android
support will be available in the upcoming version.
[1] http://www.phoronix.com/scan.php?page=news_item&px=MTA1MDU
--
Programming is difficult business.
It should never be undertaken in ignorance.
--Douglas Crockford, "Javascript: The Good Parts"
Vadim Zeitlin
K> On Mon, Feb 27, 2012 at 8:36 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
K> > (2) Implement drawing in some way.
K>
K> Instead of implementing wxGCDC and friends from scratch wouldn't it be
K> simpler to wrap an existing library? skia, cairo, agg come to mind.
It would definitely be simpler and, if we could wrap Skia, it would also
be more efficient. And we already wrap Cairo, of course (wxGraphicsContext
has an implementation using it), so this would be the simplest way.
The trouble is that using Skia seems to be possible as there are no
headers for it in the NDK and its ABI is not fixed. I didn't think about
using Cairo as I didn't know it worked on Android but now that I looked for
it there is https://github.com/anoek/android-cairo which looks like it
should work. I do wonder how exactly did they manage to port Cairo to
Android though, does anybody know?
K> What is the status of wxDirectFB?
Not really full-fledged but much more advanced than wxAndroid :-)
K> If [1] is to be believed, android support will be available in the
K> upcoming version.
K>
K> [1] http://www.phoronix.com/scan.php?page=news_item&px=MTA1MDU
Yes, I did look at DirectFB but I'm not sure it makes sense to build atop
something that is at best in experimental stage itself...
Regards,
VZ
Eric Jensen
Tuesday, February 28, 2012, 3:36:10 PM, you wrote:
VZ> I think it could be useful to retest under Vista/7, I'd expect GDI+ to be
VZ> better there. In fact, if you could extend tests/benchmarks/graphics.cpp
VZ> with your tests, this would be useful as it would allow us to compare wxDC
VZ> and wxGraphicsContext performance on all platforms.
here's a patch that extends the graphics benchmark.
Unfortunately my XP and Win7 machines have similar CPUs but very
different GPUs, so a fair comparison was not possible (XP was twice as
fast as Win7). Vista is a special case, because it's documented that
GDI always runs on the CPU there:
http://blogs.msdn.com/b/directx/archive/2009/09/29/comparing-direct2d-and-gdi.aspx
(Search for "Availability of Hardware Acceleration")
Because of the much bigger number of benchmarks, the results are a
little bit of a mess.
Remarkable however, is that rendering into a bitmap using wxMemoryDC
is *very* slow with wxGraphicsContext. This seems to indicate that GDI+
is somewhat hardware accelerated when drawing to the screen, but uses
software only when rendering into a bitmap.
Regards,
Eric
Vadim Zeitlin
EJ> Remarkable however, is that rendering into a bitmap using wxMemoryDC
EJ> is very slow with wxGraphicsContext. This seems to indicate that GDI+
EJ> is somewhat hardware accelerated when drawing to the screen, but uses
EJ> software only when rendering into a bitmap.
My benchmarks under Win7 show that wxGCDC is consistently much slower than
wxDC but it's even worse when drawing on screen:
Benchmarking dc client DC: 10000 lines done in 112ms = 11.2us/line
Benchmarking dc client DC: 10000 rects done in 173ms = 17.3us/rect
Benchmarking dc client DC: 10000 bitmaps done in 167ms = 16.7us/bitmap
Benchmarking gcdc client DC: 10000 lines done in 13758ms = 1375.8us/line
Benchmarking gcdc client DC: 10000 rects done in 2938ms = 293.8us/rect
Benchmarking gcdc client DC: 10000 bitmaps done in 2914ms = 291.4us/bitmap
Benchmarking dc memory DC: 10000 lines done in 24ms = 2.4us/line
Benchmarking dc memory DC: 10000 rects done in 21ms = 2.1us/rect
Benchmarking dc memory DC: 10000 bitmaps done in 69ms = 6.9us/bitmap
Benchmarking gcdc memory DC: 10000 lines done in 2149ms = 214.9us/line
Benchmarking gcdc memory DC: 10000 rects done in 655ms = 65.5us/rect
Benchmarking gcdc memory DC: 10000 bitmaps done in 916ms = 91.6us/bitmap
Benchmarking dc paint DC: 10000 lines done in 91ms = 9.1us/line
Benchmarking dc paint DC: 10000 rects done in 170ms = 17us/rect
Benchmarking dc paint DC: 10000 bitmaps done in 165ms = 16.5us/bitmap
Benchmarking gcdc paint DC: 10000 lines done in 14166ms = 1416.6us/line
Benchmarking gcdc paint DC: 10000 rects done in 4242ms = 424.2us/rect
Benchmarking gcdc paint DC: 10000 bitmaps done in 3584ms = 358.4us/bitmap
Honestly, I didn't expect the results that bad for wxGCDC...
Regards,
VZ
Stefan Csomor
>EJ> Remarkable however, is that rendering into a bitmap using wxMemoryDC
>EJ> is very slow with wxGraphicsContext. This seems to indicate that GDI+
>EJ> is somewhat hardware accelerated when drawing to the screen, but uses
>EJ> software only when rendering into a bitmap.
>
> My benchmarks under Win7 show that wxGCDC is consistently much slower
>than
>wxDC but it's even worse when drawing on screen:
Could you post the lines you used for benchmarking, I'd like to profile
some possible shortcuts, and also look at the results when turning off
things like subpixel drawing etc. that are not available under dc at all
Thanks,
Stefan
Vadim Zeitlin
SC> >EJ> Remarkable however, is that rendering into a bitmap using wxMemoryDC
SC> >EJ> is very slow with wxGraphicsContext. This seems to indicate that GDI+
SC> >EJ> is somewhat hardware accelerated when drawing to the screen, but uses
SC> >EJ> software only when rendering into a bitmap.
SC> >
SC> > My benchmarks under Win7 show that wxGCDC is consistently much slower
SC> >than wxDC but it's even worse when drawing on screen:
SC>
SC> Could you post the lines you used for benchmarking,
The code is in tests/benchmarks/graphics.cpp. There is no makefile for it
but basically you can just do the usual
g++ -o graphics graphics.cpp `wx-config --cxxflags --libs base,core`
to build it.
SC> I'd like to profile some possible shortcuts, and also look at the
SC> results when turning off things like subpixel drawing etc. that are not
SC> available under dc at all
I realize that wxGCDC does more than wxDC for e.g. line drawing as wxDC
doesn't support AA. But I really can't explain the huge difference when
drawing bitmaps -- what could wxGCDC do differently here?
Regards,
VZ
Eric Jensen
Thursday, March 1, 2012, 3:03:04 AM, you wrote:
VZ> My benchmarks under Win7 show that wxGCDC is consistently much slower than
VZ> wxDC but it's even worse when drawing on screen:
[...] results cut
VZ> Honestly, I didn't expect the results that bad for wxGCDC...
I did some further research here, the problem is not only GDI+, but
wxGCDC itself. When drawing a wxBitmap it will be converted to a
wxGraphicsBitmap first. This conversion takes place pixel-by-pixel and
is pretty slow.
( see wxGDIPlusBitmapData ctor in /src/msw/graphics.cpp )
So when working with wxGraphicsContext, using a wxGraphicsBitmap
should be encouraged. Having that said, working with wxGraphicsBitmap
only is a little inconvient at the moment, as it doesn't even provide
methods to get the width or height, so you have to keep the original
wxBitmap around for that.
Regards,
Eric
Vadim Zeitlin
EJ> I did some further research here, the problem is not only GDI+, but
EJ> wxGCDC itself. When drawing a wxBitmap it will be converted to a
EJ> wxGraphicsBitmap first. This conversion takes place pixel-by-pixel and
EJ> is pretty slow.
EJ> ( see wxGDIPlusBitmapData ctor in /src/msw/graphics.cpp )
It definitely shouldn't be done every time when the bitmap is drawn.
EJ> So when working with wxGraphicsContext, using a wxGraphicsBitmap
EJ> should be encouraged.
Of course.
EJ> Having that said, working with wxGraphicsBitmap only is a little
EJ> inconvient at the moment, as it doesn't even provide methods to get the
EJ> width or height
This seems really strange and is almost certainly an oversight. At least
GDI+ Bitmap definitely can returns its width and height and it should be
possible to implement it everywhere by just storing the size if necessary.
Any patches doing this would be very welcome.
Regards,
VZ
Stefan Csomor
>EJ> Having that said, working with wxGraphicsBitmap only is a little
>EJ> inconvient at the moment, as it doesn't even provide methods to get
>the
>EJ> width or height
>
> This seems really strange and is almost certainly an oversight. At least
>GDI+ Bitmap definitely can returns its width and height and it should be
>possible to implement it everywhere by just storing the size if necessary.
>Any patches doing this would be very welcome.
yes, keeping a copy of wxBitmap around would be a waste, but having
metadata available would definitely be reasonable.
Best,
Stefan