Re: [platform-swt-dev] Re: SWT and Photon

["Chris McKillop" <cdm@xxxxxxx>]

>

> I'm going to apologize up front for posting this message to the
> platform-swt-dev mailing list without asking you first. The comments you
> were making are *exactly* the kind of discussion I would like to see
> happening on the mailing list, so I'm going to use this message as a
> seed...
>

Love to use the list - no worries at all. :)

>
> What you say below about the "Photon style guide" reminded me of one of
> the places where you have to watch out for "the bigger picture":
>   - there are some places in the eclipse UI where code was made to work a
> particular way because we were trying to behave like the platform,
>   - and there are other places where the _eclipse_team's_ UI design people
> specified a particular appearance,
>   - and there are other places where some of the text of the UI was
> mandated by the legal people to have a certain look&feel (like the About
> dialog),
>   - and there are other places where the swt team made it work a certain
> way just 'cause it seemed like a good idea. :-)
>  When each of these cases is occurring is not always obvious.
>

Yep - and I am not really doing anything drastic.  In fact, I have examples
online of the differences in the chnages I am doing:

http://qnx.wox.org/swt/

Please - anyone and everyone comment.  Thus far it has primarily been
picking which fonts are being used and how the Group widget is created.  The
changes are somtimes subtle, so it is best to have both the before and the
after shots side-by-side.


>
> As to the rest of what you've said, one of the fundamental design
> philosophies of SWT is _no_custom_C_code_. When you talk about adding new
> JNI methods below, I got *very* nervous. At the very least, before you go
> down that path, you need to provide us with compelling benchmark
> information which shows that writing C code equivalents of some of the
> existing methods will be a *significant* performance win. That's both at
> the microscopic and the macroscopic (i.e. eclipse runs significantly
> better) level. Just so you know, our experience on other platforms has
> been that, writing C code for performance tuning purposes frequently
> provides very little real-world benefit versus the equivalent JIT-compiled
> java code.
>

See, I am not trying to change things algorithmically.  I totally agree,
doing the algorithims in java vs. C will not be a huge difference in speed.
But, if I can remove expensive system calls that don't need to be made when
the function is written in C, there will be a big BIG win (thinking malloc,
memmove, free).  So, where does one draw the performance increase lines? ;)
It is very hard to measure the performance under Eclipse (macroscopic) so
that will have to be a "feel" issue.  As for the microscopic - Would a 10%
increase in speed justify the change?  More?  Less?

Just so you know, I will be doing my test cases on a P166 - both macro and
micro.  This way speed changes will be more prononouced.  And it is also
more indicative of the class of processors QNX and OTI's customers are using
today with Photon.

    chris