On Mon, 24 Mar 2003, Keith Packard wrote: > Around 18 o'clock on Mar 24, Allen Akin wrote: > > > Keith was willing to address the UI folks' requests fairly directly, even > > if some of the resulting features couldn't be supported by the hardware or > > involved infrastructure differing from what was developed for OpenGL. That > > wasn't true for a lot of us in the OpenGL community. > > I tried to strike a balance between what hardware I knew about provided and > what 2D applications were already busily doing in software. Given that I > also wanted to migrate rendering across the wire for networked use, > providing software implementations of rendering operations needed by > applications will end up a net win in performance. > > Even still, I think nearly all of Render matches the hardware pretty well; > it's a tiny little extension, providing image compositing and primitive > geometric objects and not a whole lot else. I'd be interested to know > what areas are broken so that we can explore how best to fix them. I think the Mask + Src compositing model is OK, even the component alpha. Hardware is going in the direction were you can do just about any type of operations on data coming from the textures. The bigger problems were things like repeat, which becomes difficult if the hardware doesn't support non-power-of-two textures, which, as far as I can tell still includes alot of hardware. Maybe Longhorn will change this. I don't know. Also the union of Drawable and Picture presents some problem. That's because many hardware don't support linear formats for textures or drawables, or if they do, they support them with limited functionality. I haven't looked at the transform stuff. Is this just a transformation matrix applied to the texture coordinates? If so, that's probably OK, but it throws the precise rendering model out the window. Overall I think the non rectangular geometry in render presents the biggest problem. You're pretty much going to be rendering masks in software that you can pass to the hardware for composite. Modern GPUs don't have the precision you need to make this work. Any sort of subpixel thing is problematic. Also, as mentioned there is a transition to floating point for framebuffer formats. Big problems with the precise rendering model there. Mark.
[X.Org] [XFree86] [XFree86] [XFree86 Newbie] [IETF Annouce] [Security] [Bugtraq] [Yosemite] [MIPS Linux] [ARM Linux] [Samba] [Linux Security] [Linux RAID] [Linux Resources]