| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I thought it was best to give you what I have so far
for your input and code review instead of giving you
everything all at once.
This CL implements JSONObject which has a mechanism
for adding stuff to be serialized as JSON to the
serialization code. Since JSONObject is a serialization
only object it seemed okay to put Serialize code
inside.
I opted to pre-declare JSONFloat and JSONOptionalFloat
because I felt it made the code more error free.
I had made it were you could just have JSONFloat and
then with RegisterJSONValue you'd pass in optional
or not but this way, declaring the field in a class
makes it more explicit.
CameraInfo is the first class that uses it. I'm not
set on exactly how it is serialized. Whether it's
as "object: { ... }" inside the "properties" section
or whether it should have its own section. I think
I won't know what until I actually write the
deserialization code. That's not imporant for this CL
This code, even if checked it, is not used yet
as the import code, collada.cc, is not yet creating
any of these objects. That's in another CL if you want
to take a look
http://codereview.chromium.org/160007
That CL will have to have lots of o3djs changes,
corresponding sample changes and corresponding
selenium test changes.
Review URL: http://codereview.chromium.org/160008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21515 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make the javascript render callback or not.
Generally you want to pass true, but if the render is happening
in non-windowed mode (eg on a Mac) and is in response to an update
event rather than a timer, it can be useful to pass false to prevent
the javascript code triggering another update and causing an infinite
calback loop. Case in point is the custom camera example, which
modifies some HTML form text fields on render callback, which on
Firefox causes a plugin invalidation and round and round we would go.
Review URL: http://codereview.chromium.org/159181
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21473 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/159315
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21471 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rather than O3D, to allocate and register shared memory segments.
This is required in order to work in Protected Mode Internet
Explorer on Windows Vista and later. Fixed preexisting bugs in
MessageQueue related to shared memory mapping failures and
corruption of concurrent incoming messages.
Added the MessageQueue unit tests and Chrome's ConditionVariable
class to the build. These tests required restructuring and
multithreading. Wrote simple framework which detects test
failures and timeouts in child threads and reports them to the
main thread. Restructured existing MessageQueue tests. Added unit
test for Register/UnregisterSharedMemory and stress test for
above concurrency bug.
Buganizer ID: 1997023.
Review URL: http://codereview.chromium.org/155947
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21426 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/155953
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21407 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
and update related unit tests and selenium reference img.
Review URL: http://codereview.chromium.org/159180
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21299 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
It still doesn't but I want to checkpoint these changes.
Review URL: http://codereview.chromium.org/155890
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21279 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
It fixes at least two real bugs, one in the tar generator, and one
in stream_bank.h.
Review URL: http://codereview.chromium.org/159168
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21227 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bitmaps and being able to flip them, scale them, etc...
Basically this just makes it possible to download a RawData
directly which you can then pass you'll be able to pass to
pack->CreateBitmapFromRawData.
Some design comments:
I used SetFromFile instead of making a different constructor
since it seemed wrong to do file IO in a constructor. Given
that SetFromFile is private I don't think this is a problem
since you can't call it directly.
Also, I thought about loading the file first and then calling
the original constructor but it seemed like a waste to load
the file into memory, then copy it to a new buffer when I could
just load it directly.
Finally I made it take a String instead of a FilePath because
it meant other places had to do less work.
Review URL: http://codereview.chromium.org/149784
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21015 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/155401
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21000 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both Curve and Skin have the issue that the format
does not store any kind of length.
So, I serialize a Skin to binary, followed but some other data
in the same binary. Then at runtine I can deserialize the Skin
and call mySkin.setFromRaw(rawData, validOffset, INVALID_LENGTH)
At which point there the possibility, how ever small, that
the skin deserialization code will read into the next
chunk of binary data in the RawData. Data that does not belong
to it.
The best solution IMO would be to add a length or count to
the Skin and Curve formats since then, like Buffer, it would
know exactly how much data is expected and if the length
passed in does not match the length the format says it needs
it would fail.
Unfortunately, that would break all assets out there.
This fix just makes sure that if we do get any kind of error
the data is not left in the Skin or Curve like it was before.
Should probably do the same with Buffer.
Review URL: http://codereview.chromium.org/155599
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20841 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
yet consistent across platforms, and the old way won't work on the Mac.
Also, updated to include bitmap.idl in the idl build, and fixed a signed/unsigned
mismatch warning in bitmap.cc
Review URL: http://codereview.chromium.org/155612
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20830 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/149684
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20754 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/155556
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20713 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/150058
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20700 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
code changes.
Review URL: http://codereview.chromium.org/149572
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20543 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
handler. This fixes deadlocks and slowdown in Chrome. The approach is strange. It asynchronously opens the url data:, and then invokes Tick from the finish callback. This is the simplest approach I could think of that hide widespread browser support. NPN_PluginThreadAsyncCall would be ideal but it is supported by all browsers we currently support.
Review URL: http://codereview.chromium.org/149415
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20517 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
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/155185
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20117 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
http://codereview.chromium.org/149236
The change SourceBuffer to use scoped_array
and they add a test for Class::unqualified_name.
Review URL: http://codereview.chromium.org/149300
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20115 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
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/147237
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19859 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
into the gyp build. 21 of them fail, but that is only because they don't
have test input yet -- I haven't added the build code that copies
the test inputs into the build dir yet.
Review URL: http://codereview.chromium.org/147129
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19778 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/150089
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19749 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19663 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
Arrays of floats, float2, float3, float4, Matrix4,
int, bool and sampler are all supported.
I'll enable the test for selenium and check in
a screenshot in another build.
Review URL: http://codereview.chromium.org/125188
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19548 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
The issue for indexed images is the bits per channel is how many bits are used to look up the value
in the palette. The value that comes out is an RGB value.
Review URL: http://codereview.chromium.org/149060
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19543 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
quiets the unit test, but has a todo under the actual code. To make all examples run, this should be completed, but if we're going ot eliminate the texture path in favor of the sampler path, then it doesn't make sense to fill this in if we'll delete it shortly.
Review URL: http://codereview.chromium.org/146133
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19268 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19216 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
but only in the GYP build. The GYP build uses a newer chrome/base that
doesn't provide down_cast<> anymore.
Review URL: http://codereview.chromium.org/146092
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19140 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
and modifies the DEPS file extensively to match.
Review URL: http://codereview.chromium.org/131116
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19091 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
software renderer enabled with registry entry even if hardware is capable. Build scripts copy the software renderer dll to the plugin directory on an intall build.
Review URL: http://codereview.chromium.org/147039
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19070 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mostly these are fixes to warnings (signed/unsigned mismatches
were the most common), and some changes to include paths.
I've updated the build.scons files and DEPS file to match these
changes so that the scons build will still function with these
changes.
Review URL: http://codereview.chromium.org/146047
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19062 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18953 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18600 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
files as well as scons-out etc...
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18599 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18598 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
doesn't show stuff we don't care about.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18595 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
examples, but wanted to get the compile fixes checked in.
Pulling out the main.scons so as not to affect the build.
Review URL: http://codereview.chromium.org/125169
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18571 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add a just-use-the-current-display-mode flag.
* Make the sample use more parts of the API.
* Correct the spelling of full-screen as per Google's policy.
* Check for valid mode when the user gives it to us.
* Expose clearFullscreenClickRegion to JS.
* Fix a typo in convolution while I'm in there.
Review URL: http://codereview.chromium.org/126034
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18477 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/126173
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18475 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
on the screen
Review URL: http://codereview.chromium.org/126018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18300 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
case of blocking errors or EOFs on NACL handles.
Review URL: http://codereview.chromium.org/118258
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18070 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wild.
This CL fixes that as follows.
If there is no 'o3d_features' argument passed to the plugin it assumes the code
using the plugin is old and turns on the features that broke backward compatibility.
Otherwise, the utility libraries always pass in a o3d_features argument from this
point on so it will work the new way (ie, certain features must be requested).
Also, the requested version is passed in as well. This way we can adjust the API
by version number later.
Unfortunately, as it is, neither the o3d_features argument is required nor
is the version number which means if someone is not using the o3djs libraries
it would be possible for them to make something that we would break later.
We could maybe fix that by requiring a version number and failing if one is
not passed in although old code will still not give us a version number so I'm
really not sure how to handle that case.
Review URL: http://codereview.chromium.org/118050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17994 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
better.
Specifically, it takes the original VertexBuffer and
splits it. One VertexBuffer contains the parts fields
that get skinned. (POSITION, NORMAL, etc...) The other
VertexBuffer contains the fields that don't get Skinned.
(COLOR, TEXCOORD, etc...)
That way instancing you can share the non-skinned
VertexBuffer.
The next step is to not serialize the skinned
VertexBuffer's contents.
Review URL: http://codereview.chromium.org/118156
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17942 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
|