summaryrefslogtreecommitdiffstats
path: root/o3d/plugin/idl
Commit message (Collapse)AuthorAgeFilesLines
* Cleanup Renderer.gman@google.com2009-08-251-3/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make Mac also look for O3D_FORCE_SOFTWARE_RENDERERgman@google.com2009-08-241-0/+22
| | | | | | | | | | | | | | environment variable. In the Mac version, the place it's added lets one instance use the hardware renderer and another instance use the software renderer. The windows version does this as well. Review URL: http://codereview.chromium.org/173248 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24127 0039d316-1c4b-4281-b951-d872f2087c98
* Changes needed to make "all" build complete, including fixing the generated ↵maf@google.com2009-08-191-3/+0
| | | | | | | | converter tool. Review URL: http://codereview.chromium.org/173045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23721 0039d316-1c4b-4281-b951-d872f2087c98
* A bunch more docs fixesgman@google.com2009-08-193-1/+6
| | | | | | Review URL: http://codereview.chromium.org/171070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23679 0039d316-1c4b-4281-b951-d872f2087c98
* expose Bitmap to JavaScript.gman@google.com2009-08-192-26/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Also added Texture.drawImage(canvas...) There's still the big question of whether we should flip textures by default in the o3d code. Currently I'm flipping them by default in o3djs.texture.createTextureFromRawData and I'm flipping them by default in o3djs.canvas.CanvasQuad.updateTexture. I'm torn whether or not I should be flipping them. I feel like 2d examples and examples of displaying images, like a picasa viewer, would be simpler if we didn't flip by default but the problem then is if you load some textures through a collada scene they'll be flipped the opposite of any textures you load by hand. Review URL: http://codereview.chromium.org/171060 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23678 0039d316-1c4b-4281-b951-d872f2087c98
* Change StreamBank to inherit from VertexSourcegman@google.com2009-08-171-24/+1
| | | | | | | | 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
* A few more cleanup items for bitmap andgman@google.com2009-08-121-1/+2
| | | | | | | message_Commands git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23138 0039d316-1c4b-4281-b951-d872f2087c98
* Changes to Bitmap before exposing to JavaScriptgman@google.com2009-08-113-29/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add return type to docs for getRectgman@google.com2009-08-081-0/+2
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22872 0039d316-1c4b-4281-b951-d872f2087c98
* This CL adds client.toDataURL which gets the contentsgman@google.com2009-08-081-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add nonPowerOfTwoTextures to clientInfogman@google.com2009-08-081-0/+11
| | | | | | | | | so that video can decide to use power of 2 if it needs to. Review URL: http://codereview.chromium.org/164210 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22860 0039d316-1c4b-4281-b951-d872f2087c98
* This CL adds texture.getRectgman@google.com2009-08-071-0/+40
| | | | | | Review URL: http://codereview.chromium.org/165118 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22765 0039d316-1c4b-4281-b951-d872f2087c98
* This completes the building of o3d.msi from the GYP build.gspencer@google.com2009-08-061-1/+3
| | | | | | Review URL: http://codereview.chromium.org/164044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22680 0039d316-1c4b-4281-b951-d872f2087c98
* oops, forgot these filesgman@google.com2009-08-061-14/+9
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22584 0039d316-1c4b-4281-b951-d872f2087c98
* A step in exposing Bitmap to JavaScript.gman@google.com2009-08-062-34/+82
| | | | | | | | | | | | | | | | | | | | | The plan is to make pack.createBitmapFromRawData return an array of bitmaps. 1 bitmap if it's a standard 2d image 6 bitmaps if it's a cubemap N bitmaps if it's a volume map. The bitmaps will have a semantic so you can look at them and tell they were from a volumemap, a cubemap or a 2d image. On the way I'm attempting to clean up the code. Moving stuff out of Bitmap the did not belong there and Refactoring Bitmap so there are less If Format = stuff. Review URL: http://codereview.chromium.org/164034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22583 0039d316-1c4b-4281-b951-d872f2087c98
* Added default values to property documentation.gman@google.com2009-08-0524-35/+139
| | | | | | | | Fixed a few more docs issues. Review URL: http://codereview.chromium.org/159894 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22463 0039d316-1c4b-4281-b951-d872f2087c98
* Add SetRect to Texture2d and TextureCUBEgman@google.com2009-08-031-201/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Asynchronous tick now uses NPN_PluginAsyncCall.URL streaming callbacks are ↵apatrick@google.com2009-08-032-4/+10
| | | | | | | | 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
* This updates the DEPS to bring them in line with the versionsgspencer@google.com2009-07-232-3/+3
| | | | | | | | | | | that Chrome is currently using, and it removes "files" from the NPAPI include paths and file location in third_party so that we can be consistent with other Chrome third party directories. TEST=build using gyp and scons and ran unit tests on each. Review URL: http://codereview.chromium.org/159277 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21415 0039d316-1c4b-4281-b951-d872f2087c98
* These are gyp file changes that start to make the Mac GYP build work.gspencer@google.com2009-07-221-3/+11
| | | | | | | | 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
* The compiled version of the o3djs libs WORK!gman@google.com2009-07-2022-6/+173
| | | | | | | | | | | | | | | | | | | Sadly there is some really strange voodoo to make it work. util.js was using document.getElementsByTagName('script') and it was not returning all the scripts. Lots of dump() lines later the voodoo of calling document.getElementsByTagName('script').length (the length is important) in some place earlier in the code fixes the issue. Also, added the copyright to the compiled file Added parameter docs Review URL: http://codereview.chromium.org/159049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21085 0039d316-1c4b-4281-b951-d872f2087c98
* Add RawData request in preparation for manual loading ofgman@google.com2009-07-172-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* This changes how we do gyp targets that generate code because GYP isn'tgspencer@google.com2009-07-161-201/+68
| | | | | | | | | | 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
* More docs changes.gman@google.com2009-07-151-2/+1
| | | | | | | | | | | | | | | *) Made enums show up *) Right justified return type *) moved class name to right column in summary area *) pretty print code examples *) changed [inherited] to [inhertied from <class>] *) Changed name in details area to Class.Name or Namespace.Name *) Add subtypes so ParticleEmitter shows up in docs for o3djs.particle *) Grabbed new nixysa so properties show up Review URL: http://codereview.chromium.org/155600 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20806 0039d316-1c4b-4281-b951-d872f2087c98
* expose bitmap in js.yux@google.com2009-07-153-0/+153
| | | | | | Review URL: http://codereview.chromium.org/150058 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20700 0039d316-1c4b-4281-b951-d872f2087c98
* Add polygon offset docpiman@google.com2009-07-111-2/+12
| | | | | | | Review URL: http://codereview.chromium.org/155385 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20456 0039d316-1c4b-4281-b951-d872f2087c98
* Add ClientInfogman@google.com2009-07-091-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add missing Param IDL for ParamRenderSurface andgman@google.com2009-07-082-45/+68
| | | | | | | | ParamRenderDepthStencilSurface. Review URL: http://codereview.chromium.org/149298 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20116 0039d316-1c4b-4281-b951-d872f2087c98
* Review URL: http://codereview.chromium.org/147258ericu@google.com2009-07-021-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19795 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a few more doc errors.gman@google.com2009-06-303-4/+12
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19575 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes lots of docs issues in the IDL files.gman@google.com2009-06-2616-36/+100
| | | | | | Review URL: http://codereview.chromium.org/147144 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19430 0039d316-1c4b-4281-b951-d872f2087c98
* This adds in the GYP files needed for our GYP build,gspencer@google.com2009-06-242-0/+320
| | | | | | | 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
* Review URL: http://codereview.chromium.org/147062ericu@google.com2009-06-241-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19087 0039d316-1c4b-4281-b951-d872f2087c98
* These are code changes required to make the GYP build work.gspencer@google.com2009-06-232-5/+5
| | | | | | | | | | | | | 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
* Undoing gcl bug damage AGAINgman@google.com2009-06-172-8/+6
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18600 0039d316-1c4b-4281-b951-d872f2087c98
* adding svn:ignore properties to ignore .o3dtgzgman@google.com2009-06-172-6/+8
| | | | | | | files as well as scons-out etc... git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18599 0039d316-1c4b-4281-b951-d872f2087c98
* Undoing gcl bug damagegman@google.com2009-06-172-8/+6
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18598 0039d316-1c4b-4281-b951-d872f2087c98
* Adds a bunch of svn:ignore properties so that svn statusgman@google.com2009-06-172-6/+8
| | | | | | | 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
* Polish full-screen mode a bit:ericu@google.com2009-06-162-24/+61
| | | | | | | | | | | | | * 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
* * Raising the pdiff threshold for the beachdemo test to correct pulse ↵vangelis@google.com2009-06-042-8/+11
| | | | | | | | | | | | | failure (fails with the same diff on my PC) * Added comment about the valid values for the min, mag and mip filters in sampler.idl * Cleaned up some typos in texture.idl * Changed the texture-set-test to use POINT filter for min and mag to avoid issues with h/w that doesn't support linear filtering of floating point textures * Bumped up rev for o3d_assets to include new reference image for texture-set-test Review URL: http://codereview.chromium.org/118212 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17582 0039d316-1c4b-4281-b951-d872f2087c98
* Final merge from O3D Perforce tree.gspencer@google.com2009-05-291-45/+164
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17243 0039d316-1c4b-4281-b951-d872f2087c98
* This is the O3D source tree's initial commit to the Chromium tree. It gspencer@google.com2009-05-2757-0/+8778
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
generated by cgit v1.1 at 2025-01-27 02:26:02 +0000