| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL changes Bitmap to no longer be a cubemap.
Instead there is a function, Pack::CreateBitmapsFromRawData
that returns an array of bitmaps.
For a 2D image 1 bitmap is returned
For a cubemap 6 bitmaps are returned
eventually for a volumemap N bitmaps will be returned.
To distinguish between 6 bitmaps that are a cubemap
and 6 bitmaps that are slices of a volumemap there
is a Bitmap::semantic which tells what the bitmap is
intended for.
In a previous CL I had started to break Bitmap into
classes like Bitmap8, BitmapFloat, BitmapDXT1.
These were not intended to be exposed to JavaScript,
only to make the internal code get rid of lots of
if format == or case(format) stuff.
But given that it's working as is and there are more
pressing things I'm not planning to do that right now.
I can delete the classes if you think I should.
Note: This is still not 100% done. I still need to
deal with the flipping issues or at least test.
I probably need to add more tests as well.
I also got rid of any mention of resize_to_pot in
the command buffer version. Client side command
buffer should not have to deal with POT/NPOT issues.
I also moved the pot/npot stuff out of generic code
and into the platform specific code. The generic code
is not supposed to care.
This is slower than the old way but it feels cleaner.
A few issues I'm looking for input on. There's
a function, Bitmap::GenerateMips(source_level, num_levels).
It generates mips as long as they 8Bit textures.
I can easily add half and float but not DXT. Right now
if you call it on DXT in debug it prints a LOG message
but otherwise it does nothing. Should I error for DXT?
On the one hand it would be good to know that it failed
so a user will not be wondering "I called it, why are
there no mips?"
On the otherhand, from JavaScript failing would mean
you'd need to check the format before calling it which
also seems less then ideal.
The other is that currently it doesn't ADD mips, it just
replaces the ones that are there. That means if you load
a 2d image and want mips you have to allocate a new bitmap
with the number of mips you want, copy level 0 from the
old bitmap to the new bitmap and then generate mips
Should I make generate mips effectively do that for you?
Basically, if you call it to generate mips on levels
that don't yet exist in the bitmap it would realloc itself
and then generate them. Is that better?
Also, I started down the path of taking out alpha_is_one.
I'm trying to decide what to do with it. Part of me wants
to take it out completely but since it's already there
maybe I can't.
If I leave it in I was thinking of making it check every
time it's called. First I'd just make it slow. Then later
if we want I could add a dirty flag and only recheck when
it's dirty. That would be a lot of work though. It would
mean wrapping Lock and SetRect and maybe a few other things
so that we could catch any writes to the texture. It might
also mean changing Lock to take read/write flags. I think
those are good changes but again, it's not important right
now. So, the question is what to do now. I can
1) Remove alpha_is_one. That might break something out there
2) Leave it in but just have it always false.
3) Make it check every time it's accessed.
4) Do the dirty flag thing.
Preference? I'm for 2 or 3 I think.
Review URL: http://codereview.chromium.org/164235
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23051 0039d316-1c4b-4281-b951-d872f2087c98
|
