Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-swt-dev] Re: SWT and Photon


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...

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.

Now, for places where we just "got it wrong" in the UI, it makes sense to try and better match the correct photon L&F. I just wanted to warn you that there may be cases where the eclipse story and the photon story are at odds. We've seen an example of this w.r.t. dialog text in GTK2. In this case, there is a GTK2 specification dealing with how information dialog text should be presented. Unfortunately, we can't match this, because these guidelines conflict with the eclipse provided guidelines. We also can't be *different* on GTK, because of the nightmare this would create for documentation, training materials, etc.

Note: I'm not suggesting that you don't make your changes, I just wanted to use this as an example of the kinds of things to watch out for.

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.

McQ.



"Chris McKillop" <cdm@xxxxxxx>

09/09/2002 03:16 PM

       
        To:        "Mike Wilson" <Mike_Wilson@xxxxxxx>
        cc:        
        Subject:        Re: SWT and Photon



Thanks for the detailed reply Mike!

Right now my main focus is making the SWT correct and fast on Photon.  At
the moment it has some UI issues (which I am fixing first) that make it
different from other standard apps out of QNX.  I am working with our head
UI design guy to ensure that the look-n-feel is correct and consistent with
the Photon Style Guide (which currently lives in his head. <grin>).

Once these are corrected (and accepted) I will be looking at the issue of
performance.  The SWT on Photon is nearly complete, but it it is terribly
slow.  I fear this is where the major issues of accepting patches will
arrise.  The win32 API has a different approach from Photon for dealing with
messaging. Specifically, win32 provides a larger set of specific APIs and
also tends to push information via function arguments.  Photon, however, use
a more general API and uses stack variables to push information.  So instead
of looking at Photon's API and accounting for the difference, the SWT code
on Photon is emulating the SWT win32 binding's approach.  Trying to use
OS.PtSetResource() as an equivalent to OS.SendMessage().  This leads to a
minimum of 4 jni calls on Photon vs 1 on win32, and often includes many
more.  Worse, it includes JNI calls to things like malloc() and free() on
every event - very expensive calls to be making.  Simpling selecting a menu
and moving to a new menu will often invoke some 20-30 calls to malloc(),
memmove() and free().

So, I am going to be making changes that include mapping some SWT widget's
member functions almost directly to new JNI functions.  For example,
providing a widgetSetFont() JNI and using that inside of the Control widget
instead of the hoops it currently jumps through to set and get fonts.  Does
this sort of change seem reasonable to you?  I am certainly not interested
in changing everything, but I am looking (and profiling) to find
bottlenecks.  One of the biggest ares of change will be in the GC, since it
is used by all the custom and emulated widgets.

   chris

--
 Chris McKillop <cdm@xxxxxxx>     "The faster I go, the behinder I get."
 Software Engineer, QNX                    -- Lewis Carroll --
 http://qnx.wox.org/



----- Original Message -----
From: "Mike Wilson" <Mike_Wilson@xxxxxxx>
To: "Chris McKillop" <cdm@xxxxxxx>
Cc: "Steve Northover" <Steve_Northover@xxxxxxx>; "Silenio Quarti"
<Silenio_Quarti@xxxxxxx>
Sent: Monday, September 09, 2002 7:22 AM
Subject: Re: SWT and Photon


> [disclaimer: I'm sure there is some official description of what it takes
> to get commit rights on the eclipse.org web. If there's something I say
> here that doesn't agree with what it says there, then *it* will win.]
>
> So... There's a couple of levels of this.
>
> Because you are predominantly interested in the photon port, it might be
> enough for you to have commit rights to just the photon parts of the
> source tree. This makes you a "committer on the swt/photon port", but not
> a full "swt committer". The rules for becoming a committer for a single
> port are simpler than those for becoming a committer for the whole
> component. This was done to allow new ports to be created more easily --
> you can't start a port if no one gets commit rights for six months. It
> also means that you get voting rights on everything photon related, but
> not on the more general swt issues.
>
> Basically, to be a full swt committer, you need to have been doing useful
> work with the SWT code base for something like 6 months anyway, plus you
> have to have demonstrated a deep understanding of the SWT philosophy,
> coding style and several of the implementations. This is particularly hard
> if you don't spend time working with us here, since we really don't have a
> good set of porting documents to help you (although that's definitely
> something I want to fix). It's really just a trust issue: We need to
> believe that you could work on *any* piece of SWT without breaking it, but
> more than that, without making it seem inconsistant with the rest of the
> code. Getting commit rights here would require studying the code on all of
> the platforms, discussing it with us on the mailing list, verifying the
> fixes you do against photon are not found in other platforms (or if they
> are, providing fixes for them there as well), etc.
>
> Because the photon port has already started, and indeed is mostly "done",
> you would still have to have spent some period of time doing useful work
> (i.e. providing good patches) with the existing code (say 4 months?), plus
> you need to have demonstrated both a strong knowledge of photon (shouldn't
> be too hard :-) ) and a relatively rich understanding of how SWT on photon
> works as well as how the portable bits of SWT drive that code. A good test
> for this would be that, the patches you provide are being accepted without
> (significant) edits. What we have found in the past is that, when people
> first start working with the code, they often make fixes which solve the
> particular problem, but which don't make sense in the larger context. We
> would be looking for signs that you do understand this larger context.
>
> In the mean time, we'll try to look at any patches you do provide as soon
> as you send them. By all means, post on the mailing list if you've
> annotated a bugzilla report with a patch so we'll know to check it out.
> We'll try to give you useful feedback on each of the patches you provide.
> This will likely be done on the mailing list, so that all the other
> potential committers can benefit from it as well.
>
> Even if you are just going to *look* at a problem, you should probably
> post and let us know, so that we don't duplicate the effort. It might also
> be good to talk to Silenio Quarti or Steve Northover about what particular
> areas they think need to be looked at, since they're the ones who are most
> involved with the port.
>
> anyway, I hope that helps and I'm looking forward to see your work,
> McQ.
>
>
>
>
>
> "Chris McKillop" <cdm@xxxxxxx>
> 09/06/2002 07:30 PM
>
>
>         To:     <Mike_Wilson@xxxxxxx>
>         cc:
>         Subject:        SWT and Photon
>
> hey Mike...
>
> Just wanted to send you email directly.  I hope to be able to get commit
> access sometime in the future since the performance and correctness of the
> SWT/Photon bindings are as much in our (QNX) interest as OTI's.  However,
> I
> also know we have not been playing by the rules in the past (patches to
> the
> newsgroups and mail lists) so we will have to build up to getting the
> commiter responsibility.
>
> I am not sure what the criteria is within the SWT team for external
> commiters, if you have any (even vague) ideas for what/when/where you will
> nominate people, I would love to knowm them. ;)
>
>     thanks,
>     chris
>
> --
>   Chris McKillop <cdm@xxxxxxx>     "The faster I go, the behinder I get."
>   Software Engineer, QNX                    -- Lewis Carroll --
>   http://qnx.wox.org/
>
>
>
>
>




Back to the top