| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
DISPLAY_MODE_DEFAULT only for now (mode switching is evil anyways ;) ). Small bit of code cleanup in renderer.h.
TESTED=entered and exited fullscreen; tested leaving with Esc, Alt+F4, click on region, and right-click on taskbare -> Close; all with both Compiz on and off, on gHardy.
Review URL: http://codereview.chromium.org/258004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27732 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
O3D.
What happens is client.toDataURL creates a RenderSurface
and DepthSurface, sets those as the current Surface
then renders. It then calls Surface::GetBitmap to
get the pixels in the bitmap.
The complications are
1) I needed to make Renderer::StartRendering /
Renderer::FinishRendering be nestable because the
Renderer::SetRenderSurface required StartRendering
to already have been called. I didn't see a cleaner
way to do this but I'm happy to change it if you
have a better idea.
2) Since we can only create POT RenderSurfaces
I added a clip_width / clip_height to render surfaces.
Renderer::SetViewport uses these values so we end up
rendering correctly to the top/left area of the
POT render surface.
3) Doing it this way means that screenshots are NOT
anti-aliased. I feel like that issue can be handled
later. It's more important that toDataURL work now
than it have the ultimate best results. (I hope). It
probably means I'll need to create all new reference
images.
4) I was wondering we we should expose SetClipWidth
to JavaScript. Given that we require POT render surfaces
they should always get the same results on all hardware.
Or, rather, we could just allow the user to create NPOT
RenderSurfaces. Under the hood they'd get a POT surface
but the clip_width/clip_height would be set to the size
the requested. There would have to be a note that texture
wrapping only works if the size if POT.
5) I had to split FinishRendering into FinishRendering
and Present since when taking a screenshot nothing will
be drawn to the backbuffer and so I don't want a
present to happen.
Review URL: http://codereview.chromium.org/174594
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24781 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I believe there were some mis-understandings
about the code. It's supposed to work
StartRendering();
BeginDraw();
EndDraw();
BeginDraw();
EndDraw();
BeginDraw();
EndDraw();
FinishRendering();
To try to enforce correct usage I separated
some platform dependant stuff from shared
stuff and added a few flags.
Also in this CL I made Texture::GetRenderSurface
not require a pack. This is so I because it feels
cleaner that way but also because I wanted to
use surfaces without a pack to take a screenshot.
Finally I put some screenshot code in for GL.
Also fixed some bugs with locking textures.
1) I thought it was x, y, width, height but it's
actually x1, y1, x2, y2
2) I was using width in places I should have been
using mip_width
Review URL: http://codereview.chromium.org/174199
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24188 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the client area as a data url (which is a base64
encoded string of a png file)
data urls are part of the HTML5 standard and supported
by firefox, safari and chrome.
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-canvas-todataurl
That means you can now do this
var dataURL = client.toDataURL();
// make an IMG tag display the screenshot
someImgTag.src = dataURL;
// use the IMG tag to draw into a canvas
someCanvasContext.drawImage(someImageTag, ...);
It also means there is no need for the test builds
anymore "test-dbg-d3d", "test-opt-d3d" etc as
toDataURL is part of the public API and can
therefore always be used to take screenshots
in any build.
I updated the selenium code to use it.
There are a few issues:
1) The GL version has the same limitations as taking
a screenshot before. Namely that the client area
must be on screen. We need to fix this.
2) We need to add support for origin-clean. See
https://tracker.corp.google.com/story/show/180334
Review URL: http://codereview.chromium.org/164130
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22869 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
is not built or referenced at all by the chrome build yet, and doesn't
yet build in it's new home. We'll change that shortly.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17035 0039d316-1c4b-4281-b951-d872f2087c98
|
