Re: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot

["Boris Shingarov" <Boris_Shingarov@xxxxxxx>]

Keeping what we have now is *not* error prone; going ahead to maintain a caching logic is complex and may be error prone.  Speed: in the "ready image for use" scenario, there is an extra server-to-client transfer, which theoretically will slow things down.  The real problem currently is alpha support (we only mantain a 1bpp mask).

My position:  We should *not* hurry to change Image right now.
One interesting possibility would be to eliminate the problem completely by separating the two uses of Image that Seth mentioned ("for drawing" vs. "ready for use") in the SWT API, and represent them differently in the two cases.  However, this is a breaking change, with all of the complications (the size of the Eclipse code base is comparable to the Gnome code base), so it would be quite an undertaking.  But I would veto any change in approach to Image before we have a definite "No" to this intriguing one.

"Steve Northover" <Steve_Northover@xxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 09/16/2002 09:32 AM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:        Boris_Shingarov@xxxxxxx, platform-swt-dev@xxxxxxxxxxx         Subject:        Re: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot

Agree.  SSQ and I discussed this one.  We probably wouldn't keep both
representations
around at the same time in order to save OS resources.  We are still
thinking about the
issues.

So, until the decision is made, we need to follow the "there is no right
and wrong, only the
same and different" philosophy.  In order to be the same, the tree needs to
manage the
pixbuff mapping provided this is just ugly and not slow or error prone.  On
the day when
we switch to a new strategy, all components will be changed to use the new
approach.
The idea here is to keep going and push this issue asside.  Is it a
blocker?  Nope.

One caveat ... I haven't had time to look at the actual code yet.  I'm
super busy with the
other platforms.  I'm going to get SSQ to take a look to make sure that
"just ugly and
not slow or error prone" statement is true.  SSQ?

Steve



                                                                                                                                           
                      Havoc Pennington                                                                                                     
                      <hp@xxxxxxxxxx>                 To:      platform-swt-dev@xxxxxxxxxxx                                                
                      Sent by:                        cc:      Boris Shingarov <Boris_Shingarov@xxxxxxx>                                   
                      platform-swt-dev-admin@         Subject: Re: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot        
                      eclipse.org                                                                                                          
                                                                                                                                           
                                                                                                                                           
                      09/14/02 05:49 PM                                                                                                    
                      Please respond to                                                                                                    
                      platform-swt-dev                                                                                                     
                                                                                                                                           
                                                                                                                                           




snickell@xxxxxxxxxxxx writes:
> So an option would be to provide the option of getting the pixbuf OR the
> pixmap, but rather than directly referencing them provide methods such
> as getPixmap() and getPixbuf() that either return the structure (if its
> up to date) or lazily render it from the other (if its not). In the
> normal (a) and (b) cases this would mean that no conversions would be
> done (since we would naturally create pixbufs when loading from a file,
> but pixmaps if starting from scratch).
>
> In the cases where an Image is, say, drawn to (which would use pixmap)
> and then set to a control (which would use pixbuf) it would be drawn to
> as a pixmap, and the pixbuf version marked as "dirty", and then
> re-rendered as a pixbuf when getPixbuf was called. Similarly if you load
> a file (which would use a pixbuf), and then do getPixmap. Looking at the
> current code I don't think this ever happens, but of course its a case
> that would have to work (even if rare).

This is a pretty good idea IMO.

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