[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] GTK graphics status
|
What was the original point anyway? Was it about the SWT wrappering single
API calls to the OS vs bundling a wad of native code?
If so, then I could add one additional point about this beyond debugging.
This feature of SWT is very nice for performance analysis, especiallly with
J9 MicroAnalyzer and Smartlinker Profiler. Since there is a one-to-one
mapping between an SWT native method and an OS call, I can use
MicroAnalyzer and Smartlinker profiler to get timing information on not
just java code, but OS calls. This has proven to be a lifesaver in some
situations. I used this to find a whopping performance bug on Photon. If
this was buried somewhere in a wad of C code I'm not sure I would have
found it.
-Andrew
Steve_Northover@xxxxxxx
Sent by: To: platform-swt-dev@xxxxxxxxxxx
platform-swt-dev-admin@ cc:
eclipse.org Subject: Re: [platform-swt-dev] GTK graphics status
03/20/2002 02:12 PM
Please respond to
platform-swt-dev
You just don't get the joke. Nobody likes stepping through anybody
else's code platform specific or not. Writing a C native so that people
don't have to step through code is just plain dumb. This is what you
were suggesting.
Are we going to have a useless flame war or are you going to reread
your original post and think better of it and drop it?
Steve
"Randy Hudson"
<hudsonr@xxxxxxxxxx> To:
Sent by: platform-swt-dev@xxxxxxxxxxx
platform-swt-dev-admin@eclipse. cc:
org Subject: Re:
[platform-swt-dev] GTK graphics status
03/20/02 03:10 PM
Please respond to
platform-swt-dev
My code is not platform specific. I argue that most aren't interested in
stepping through platform specific code.
I am writing to the SWT API. If something doesn't work right, I test it on
another SWT platform. If it still doesn't work right, it's my problem.
Otherwise, it's SWT's problem.
|---------+---------------------------------->
| | Steve_Northover@xxxxxxx|
| | Sent by: |
| | platform-swt-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 03/20/2002 01:28 PM |
| | Please respond to |
| | platform-swt-dev |
| | |
|---------+---------------------------------->
>
---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: platform-swt-dev@xxxxxxxxxxx
|
| cc:
|
| Subject: Re: [platform-swt-dev] GTK graphics status
|
|
|
|
|
>
---------------------------------------------------------------------------------------------------------------------------------------------|
Maybe we should replace the code you write with C natives so that people
don't have to step through it. <g>
Steve
"Randy Hudson"
<hudsonr@xxxxxxxxxx> To:
Sent by: platform-swt-dev@xxxxxxxxxxx
platform-swt-dev-admin@eclipse. cc:
org Subject: Re:
[platform-swt-dev] GTK graphics status
03/19/02 02:09 PM
Please respond to
platform-swt-dev
Scaling an Image should be fast. Developers shouldn't be subject to a
10-100x performance hit because they are using Java.
If you are looping over every pixel, would you consider doing this in
natives? I know the SWT philisophy, but I don't think the average
developer will benefit from stepping through such code in a Java debugger.
|---------+---------------------------------->
| | Havoc Pennington |
| | <hp@xxxxxxxxxx> |
| | Sent by: |
| | platform-swt-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 03/19/2002 01:03 PM |
| | Please respond to |
| | platform-swt-dev |
| | |
|---------+---------------------------------->
>
-------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: platform-swt-dev@xxxxxxxxxxx
|
| cc:
|
| Subject: Re: [platform-swt-dev] GTK graphics status
|
|
|
|
|
>
-------------------------------------------------------------------------------------------------------------------------------------|
Silenio_Quarti@xxxxxxx writes:
> When a image has transparency (e.g. icons, gifs with transparent pixel),
> SWT creates
> a GdkPixmap for the color part of the image and a GdkBitmap for the mask.
>
I guess the hard bit is "Image implements Drawable" - otherwise you
could just implement Image as a pixbuf instead of a pixmap.
> We are using GdkPixBuf to scale the GdkPixmap. If we use a different
> algorithm to scale the GdkBitmap, we might have problems, since different
> algorithms might replicate different pixels.
Good point.
> So if we use our own algorithm the scale a GdkBitmap, I believe we will
> have to
> use it the scale its associated GdkPixmap too.
As you probably know that's a world of pain, since you have around 20
common GdkImage pixel formats to deal with, each in two possible byte
orders...
> Right now, we are getting a GdkPixBuf with alha channel from the
> GdkPixmap,
> getting the mask data using GdkImage, combining them by replacing the
> alpha
> channel with appropriate values (e.g. 1 -> 255, 0 -> 0), scaling the
> GdkPixBuf and
> then redering to the destination drawable by calling
> gdk_pixbuf_render_to_drawable_alpha.
>
> This is somewhat inneficient though.
Yeah it's pretty ugly, but I can't think of anything much better. It
will be slow but not _that_ bad, as long as you don't do it on every
expose event or something.
There's a gdk_pixbuf_render_pixmap_and_mask() convenience function
too, FWIW, which you can use to generate a new pixmap/mask after
scaling the pixbuf.
Havoc
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
