Hello, > Is a "Layer" in this context a DrawObject that is semi-transparent? > i.e. uses the alpha channel? > > Or something higher level -- an offscreen bitmap that is transparent > with some non-transparent things drawn on it, that can be layered. A higher level is meant. Yes. The background of the bitmap could be transparent at some level and the drawn objects to. Full alpha support that the new GC gives us. Memory is cheap today. So this should be no issue to double buffer this layers to. > From the rest of your message, I think you mean Draw Objects that can > use alpha, but I want to be sure. > > Note that you can already do this, but making custom DrawObjects: > > http://trac.paulmcnett.com/floatcanvas/wiki/SmoothLines > > and creating a GraphicsContext inside the _Draw method. > > However, It looks like you are proposing updating the existing > DrawObjects to support Alpha, which I think is a good idea, and a long > time coming! Yes. I would touch the existing objects to at Alpha support. New objects only to add alpha are no benefit. It were a lot of work and a duplicate of code. >> For this to achieve at first step i would touch the current classes and add >> a Alpha value >> for the Color creation. For example something like this: >> >> def SetBrush(self, FillColor, FillStyle, Alpha = 255): >> >> def SetPen(self,LineColor,LineStyle,LineWidth, Alpha = 255): > This may be a good time to re-factor the DrawObject base class brush > and pen caching system -- by removing it -- I don't think it buys us > anything these days... Im dont sure. Cache wxWindows the pens and brushes. When it is not needed any more, i will remove this section of code. > > Note: it may be worth doing some performance testing for how long it > takes to create a GC from a DC. In the example in the wiki I referred > to, the GC is created in the _draw method, so ti will get re-created > with every object draw -- but that may be very fast. In which case, it > would be pretty easy to simple add GC functionality to each DrawObject > as needed. At first i would go this way. Create the GC in the drawing routine. > Another option is to pass in both a DC and GC to the _draw methods -- > then they could use or not use them as needed. Or, have the _draw > method access the GC from the Canvas itself. When I first started all > this, I was trying to keep the code decoupled, so DrawObjects didn't > need to know much about the FloatCanvas, but as you would never need a > DRawObject without a FloatCanvas, maybe there is no point -- we could > simply pass the FloatCanvas instance in to the _draw methods, and the > code could use: > > Canvas.mainDC > Canvas.HitTestDC > Canvas.GC > > as is required for that DrawObject. As statet above. At first i would start simple. Dont change to much code. So i will not introduce more errors then needed. >> My second question is, should i split the drawing routines in one for normal >> drawing >> and one for drawing in the hittest bitmap. > yes, that is probably required -- the HitTest bitmap requires that > each object be entirely drawn in one color. alpha has no use there, > and anti-aliasing can defeat the approach -- as the pixels along the > edges are a blend of the color with the background. So we'll need to > keep the hit-test drawing with regular DCs -- unless you can turn off > anti-aliasing with GCs -- not sure about that. Disabling anti-aliasing in wxWidgets could be done. There a routines for that in the documentation. wxPython dont expose this methods currently. Maybe later.
Ok. I will split the drawing routines. One for normal drawing. One for hittest drawing. > Great to have you on board enhancing FloatCanvas! > Gladly. Sharing some work is fun. You are right. Better then redoing the same thing. gruß ralf _______________________________________________ FloatCanvas mailing list [email protected] http://paulmcnett.com/cgi-bin/mailman/listinfo/floatcanvas
