| 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and deserializer. This CL still creates a o3dtgz
file, it's just that buffers, skins and curves are
stored in JSON instead of binary.
I'm not sure how useful this is but it seemed like
a possible short cut to testing out some stuff.
Another CL will add some flag so there is no
gzipped tar file, just the json.
Review URL: http://codereview.chromium.org/189003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25523 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, split Lock/Unlock into common and platform
specific parts.
This is needed to work around an apparent bug in
mac drivers where glGetTexImage apparently doesn't
always work.
This doesn't solve the issue unless we disallow
READ completely. Not sure what to about that
except make a small GL sample and report the
bug to Apple.
Review URL: http://codereview.chromium.org/173640
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25012 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24921 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
|
| |
|
|
|
|
|
|
| |
in preparation for Morph Targets
Review URL: http://codereview.chromium.org/164483
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23541 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally I was going to replace Lock/Unlock with
only SetRect (and maybe GetRect) and I did that.
But then as I was going through the code things started
not being so cool. The JavaScript texture.SetRect where
as before it allocated no memory, now it needed to allocate
a temporary buffer just to be able to write the texture.
DrawImage also would have have required copying the original
texture out using GetRect, then modifying it, then copying it
back even in D3D or it would have required a temporary buffer.
That's what happens under the hood in the GL implementation
of Texture2D but why should D3D suffer because of the of GL?
Or maybe it's a reasonable compomise the D3D should go slower
so that GL isn't twice as slow as it it could be?
So, I left Lock/Unlock and added SetRect as well.
This CL should help the video guys and we can decide if
we want to get rid of Lock/Unlock later.
SetRect is really only there because trying to make GL
act like D3D makes GL slow since we had to get a copy
of the texture from GL before Locking. SetRect, since
it is not exposing the original data doesn't need to do
that.
So, now there are both. If need to read (and write) to
the texture use Lock. If you only need to write use
SetRect.
I also fixed Lock/Unlock so they return a pitch which
is required for D3D. While I did that I made Lock/Unlock
private so you have to use the TextureXXXLockHelpers
to access the data.
I didn't do the command buffer versions.
I also added stubs for texture tests. We need to add
more tests.
I feel like a lot of clean up needs to happen.
It seesm like Bitmap should be split into
Bitmap2D
BitmapCUBE
BitmapVolume
Possibly. And maybe BitmapCube should effectively
just be typedef Bitmap2D BitmapCUBE[6] and
BitmapVolume would be std::vector<Bitmap2D>
Then we wouldn't need face and volume versions
of various functions. You'd just get the face or
the slice Bitma2D and then use the 2D functions.
We should decide if that's what we want before
pushing a new release. Otherwise we should remove
bitmap.idl from idl_scons.lst and the one sample
And ship without exposing Bitmap until we are
sure they API we are exposing is the one we want.
Review URL: http://codereview.chromium.org/159725
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22332 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
now also asynchronous.Implemented NPN_PluginAsyncCall for IE.Allowed WM_PAINT handler to be reentered because it no longer calls into the browser (except to schedule an asynchronous tick if none is pending).Fixed a bug where the EventManager would crash if an event callback called cleanUp on the client.Cleanup destroys all the packs. Doing this in NPP_Destroy seems to make Chrome timeout and fail to load the next page.Tar and GZ decoding happens on a new thread.
Review URL: http://codereview.chromium.org/155733
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22305 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with typical collada files found on the net.
Often someone will export a collada file with absolute paths
like "z:\someplace\somewhere\texture.tga" and
"k:\shared\stuff\othertexture.tga"
The converter needed a way to handle these without requiring
an artist to manually edit XML files.
I also refactored the original_data_ stuff to make sure
we don't get 2 datas for the same path. I'm doing that
in prepartion for shortening the paths where possible
using base-path or some mechanism.
Review URL: http://codereview.chromium.org/159118
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21352 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows an app to ask a few things from the client.
1) How many objects the client is tracking. This is useful
for a quick way to check that you're freeing resources.
While the developer could use client.objects.length or
client.packs[ii].objects.length that wouldend up creating
hundreds of thousands of NPObjects.
2) Check if the software renderer is being used
3) Check the approximate amount of memory used by textures.
Again, they could compute this with
client.getObjectsByClassName('o3d.Texture') but it seemed
like it might be useful.
I say approximate because I would have to dig down into
the indivdual renderers to get better info since a NPOT
card will use more memory but it didn't seem worth it.
4) check the approximate amount of memory used by hardware
buffers.
Review URL: http://codereview.chromium.org/155276
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20334 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
I named it o3djs.DestinationBuffer because it has nothing to do
with O3D. It's purely part of our sample serialization example.
Review URL: http://codereview.chromium.org/149236
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20013 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
because the collada exporters often set it to NONE or POINT.
Also make it change any collada standard Material
that is used by a Primitive with no normals to use
"constant" shading. This should make sketchup stuff
work.
Review URL: http://codereview.chromium.org/147192
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19545 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
build to succeed.
Review URL: http://codereview.chromium.org/118346
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17865 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
|
