https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #29 from Iago Toral <ito...@igalia.com> --- (In reply to Jason Ekstrand from comment #26) > (In reply to Iago Toral from comment #24) > > Jason, what do you think we should do for GL_COLOR_INDEX + GL_BITMAP? > > > > Currently this is handled as a special case in the texstore.c ubyte path > > (store_ubyte_texture), specifically, the special case handles extracting > > indexed color data so that the incoming pixels can be represented as an RGBA > > image, then do the conversion from RGBA to dst normally. > > > > We do not have a Mesa format for this combination. > > > > I think we have two options: > > 1) I guess we could create a mesa_format, detect this case specifically in > > the master function and handle it there. > > 2) The other option would be to let clients deal with it. That would involve > > letting them transform it to RGBA before they call the master function. > > > > What do you think? > > Option 2. Mesa internally hasn't supported color index in a long time, > let's not add it back. What do you mean by not supporting it internally? As I mention in my reply to Kenneth I see multiple references to GL_COLOR_INDEX in Mesa, there is a specific path to deal with it in texstore and there are even piglit tests for this that pass in master... Just to be clear, when I said "clients" in option 2) I meant clients of the master function inside Mesa (so things like texstore.c). My idea was that things like texstore would handle GL_COLOR_INDEX and take care of converting it to RGBA on their own before calling the master function, but if you say that GL_COLOR_INDEX is not really supported any more, maybe we should just ignore it completely and do nothing about it in texstore and friends? -- You are receiving this mail because: You are the QA Contact for the bug.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
