Le samedi 14 juillet 2007 à 12:08 -0400, Timothy Normand Miller a écrit : > On 7/14/07, luc marschall <[EMAIL PROTECTED]> wrote: snip > > > So, the first thing I'd like is some kind of flashy desktop wallpaper > > > to use in lieu of a title slide. I'll be using KDE with the big bar > > > at the bottom, and most projectors are 1024x768 (although it could be > > > 1280x1024, so it would be good to have options). > > By having an option, you mean to have two wallpapers? > > Though, I wonder if Impress can manage slides of different size res. > > For your needs, a screen capture with the kde's bar seems necessary to > > make this slide. > > Impress will scale the images just fine (I'm pretty sure). But I want > my "title slide" to be the desktop. In other words, I won't start out > in Impress but rather start out with a KDE desktop and switch to > Impress once I've introduced myself. > > I think KDE scan scale the wallpaper image, but I just want to make > sure that it looks as good as it can by going with the native res. So, I've misunderstood your wish (see below) > > > > > > > What I'm imaging is a big OGP or perhaps the OGP window logo at the > > > top with some kind of warp effect like it zoomed from the distance to > > > the screen. Below that, in appropriately-sized letters, "Open > > > Graphics Project", and visible but not overly emphasized, my name > > > "Timothy Miller" like in the lower right. Be sure that that fits > > > above the KDE bar at the bottom. > > I can try something, but I don't use KDE, though I can found a > > screenshot on the web. > > However, I fear that it would be a big payload for OGD1 Ok, but effect that you want is just static, it's a visual effect not an animation, right? (otherwise I can do nothing) I can refine the slide previously sent, and export it as jpg (without the kde's bar of course) Or make a gimp file. > > KDE defaults to an image on the root window, and it works just fine. > You only notice any slowness when scrolling or moving windows. Other > repaints don't seem so slow. > > Technically, the main problem is with framebuffer reads. They're much > slower than writes (over PCI). If x.org were to keep a shadow image > of the screen in host RAM and do only writes over PCI, it would > actually feel quite a bit more zippy. Another thing is that in order > to keep reads and writes coherent, the PCI controller must be sure > that writes are flushed before servicing reads. When switching back > and forth (like when doing a bitblt on the screen), the impact is > quite noticable. >
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
