> Another approach to intergating Painter would be to create another > derived DisplayDriver class, that implements all the existing > DisplayDriver functions on top of Painter. Would this be a better > thing > to do? The clipping of the client seems to be passed by the DrawData > object that each call gets, right? This reminds me of another > question That's pretty much what I had envisioned when it comes to integrating Painter. I was thinking that the DisplayDriver class would have a Painter member object which it called for various methods. DisplayDriver could handle all the messiness in setting Painter's state. I'm not very familiar with Painter's internals, but the only major thing that I would possibly want to change in it would be to see that it would call the virtual functions that are implemented by the individual subclasses so that we can still take advantage of HW acceleration. Does this sound reasonable? > I had - is the gaphics state stack already in place? AFAIK Adi has that working just as it should. --DW