--- Thomas Winischhofer <[EMAIL PROTECTED]> wrote: > Alex Deucher wrote: > > I realize that I could attempt to use it for render accel, but I > was > > hoping to tie it into Keithp's compositing extension > > (http://www.freedesktop.org/Software/TranslucentWindows) to support > > alpha blended windows, not just hw accelerated AA text. > > I don't understand under what circumstances AA text is drawn using > the > accelerated path anyway. Openoffice uses the accelerated routines for > > each and every character it draws, so does x11perf if using the > argument > -aaXXtext (which, by the way, gets boosted from 30000 to 125000/sec > if > acceleration is enabled - speak about usefulness). > > But KDE for instance never causes calls to the accelerated functions, > > neither for text nor for alpha blending in general (like for > transparent > menus, despite "RENDER" is selected for doing this in the KDE control > > center). I am riddled. I have one test application though which I got > > from the "Rasterman" Carsten Haitzler and which I used to verify the > accelerated routines do what they're supposed to. >
Very odd, I remeber the thread now. I'll take a look at your code and see what can be done on radeon, however as I recall I may need to use the 3d engine, which then gets into a whole new can of worms with regard to state and locking. I was hopeing to do it with the 2d engine only. > > Although > > thinking about it more, I guess the compositing manager could take > > advantage of the render accel to accelerate alpha blending. > > Well, I only develope for XFree86 (Linux kernel framebuffer stuff > aside). But is that really either-or? I'm sure Keith didn't dump his > RENDER extension in XServer... > No, either one. I really don't care which server I develop for, I just want to add features and I'll use what ever resources are available to me to get the job done. Keith's Xserver has compositing working and I find that intriguing. I'd like to get something similar going on xfree86 since the drivers are already substantially more featureful, but there doesn't seem to be much going on in that regard. > >>Transparent bitblits are supported by XAA's normal bitblit > functions, > > > > > > how are these used? are there any apps that use them? render? > > Plain old ScreenToScreen copy. trans_color (the last argument to the > SetupScreenToScreenCopy function) holds the (source) color which is > handled to be transparent. It's as simple as that. (hint, hint: > sis310_accel.c) And MD is right, it's not a plain "transparent" > bitblit, > it's colorkeyed in fact (but only using one color key, not a range). > Isn't used very often, though. > Thanks for the pointers. I'll take a look. It may not be worth the effort. I'm just intrigued by the eye candy and want to try and implement it. the problem is my theory and reality don't often mesh. Alex __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
