 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / May 2008Texture.FromBitmap is slow runing from debugger
Hi, Ive written a 3dmodel editor, and it works fairly well it harldy uses any cpu exept when its loading a texture from bitmap in the debugger, at all other times it hardly uses any cpu but from the debugger even in release mode it takes a second or so to load a 65k texture, with a 2ghz pc this is 10k instructions per pixel ! I cant understand what its doing here, can anyone shed any light on this ? I have the d3d debug turned off although this makes zero difference. yet it stil manages to actually draw the animated model meshes with <1% cpu. in multi viewports, also load and decode the 20mb or so of files in under 1 second. im using .. Bitmap bitmap Texture.FromBitmap(Draw3dDevice.device, bitmap, Usage.Dynamic, Pool.Default); bitmap is generated from memory. this may be somethign to do with it, but i cant think what, as I dont think it was slow when I was laoding bitmaps another way. thanks Colin =^.^= > Hi, > Ive written a 3dmodel editor, and it works fairly well [quoted text clipped - 3 lines] > to load a 65k texture, with a 2ghz pc this is 10k instructions per pixel > ! Where is the data in the Bitmap located? If you are copying data that's in video memory already, that can indeed be very slow, depending on the video bus your hardware has. Beyond that, this is just not the newsgroup for your question. Your question has zero to do with C# or .NET, and if you want a _good_ answer, you need to post it in a newsgroup where it's on-topic and people familiar with the issues are reading. For example, a newsgroup specifically about using DirectX and/or using DirectX in managed code. Pete >> Hi, >> Ive written a 3dmodel editor, and it works fairly well [quoted text clipped - 15 lines] > > Pete well its real fast without the debugger attatched... so it must be something todo with c#/.net with the way the debugger handles managed to unmanaged transitions although its using managed directx. if i press ctrl-f5 to run the program independantly or run it normally it runs and loads the bitmaps almost instantly. same in both release and debug build versions. ive tried saving the bitmap to a memory stream and loading it from there. Il ask in the gamers forum though thanks ... Colin =^.^= > well its real fast without the debugger attatched... > so it must be something todo with c#/.net with the way the debugger > handles managed to unmanaged transitions although its using managed > directx. [...] Sorry. I missed the "debugger" aspect of your question. Reading too fast I guess. I still don't know the answer, but I suppose there's a slightly higher chance of you getting an answer here than I first thought, if it's a debugger-specific problem. Pete >> well its real fast without the debugger attatched... >> so it must be something todo with c#/.net with the way the debugger [quoted text clipped - 9 lines] > > Pete Yeah i dont seemed to have stated as specificaly as i first thought that it is when the debuger is atatched and not when it isnt atatched, its no real biggy, just takes 5 seconds longer to do a debug cycle lol. im more puzzled/curious than anything else. although if i start trying to do it with masses of textures might be anoying. just like when its putting tons of stuff to the debugger output window it sits there very slow but not even using any cpu power, as if its deliberatly slowing the output so you can see it scroll past easily ? I also found a similar issue when trying to access the fast timer with the debuger it was not fast. I tried saving the bitmap to a memory stream and loading it from a stream instead of memory but made no difference, i will try doing it to a physical file next, I think I did it this way before and didnt notice any speed issue, but then again ive re written it all becuase it was all very slow before. now its al nice and fast :D many thanks Colin =^.^= Well after quite a lot of messing about I found that Texture.From... is whats making it slow even loading from a memory stream or a bitmap freshly loaded from a file, but its only slow if the app is started with the debugger, otherwise its plenty fast enough, if I use TextureLoader its fast with the debugger, but this cant load from a bitmap so I have to load from a file but fortunatly its still fast if I load from a memory stream, so il just keep my bitmaps as memory streams... my gues is that there is some byte copying going on with the Texture.From that is going acros the interface for each byte. Colin =^.^= >> well its real fast without the debugger attatched... >> so it must be something todo with c#/.net with the way the debugger [quoted text clipped - 9 lines] > > Pete > Well after quite a lot of messing about I found that Texture.From... > is whats making it slow even loading from a memory stream [quoted text clipped - 9 lines] > my gues is that there is some byte copying going on with the Texture.From > that is going acros the interface for each byte. Just a thought: it's possible you are running into some sort of driver-level copy protection. Have you tested this on different hardware (and thus different drivers)? Some drivers annoyingly will actually check to see if a debugger is present and will go through a different code path if so. Applications that do lower-level things sometimes will run into problems, and it's possible that your program's interaction with DirectX is low enough level for the driver to notice. Usually it's something really annoying like refusing to process certain kinds of input altogether. But I suppose there could be some sort of performance degradation. Ironically, if it is related to that, it's almost definitely not intentional and is just a bug in the driver's anti-copying logic (for example, it's checking constantly to see if you're creating video memory surfaces that it considers "legal" and the overhead of checking is killing your performance). It's possible that you can do some testing on your immediate hardware rather than switching computers by reducing or turning off hardware acceleration in the video driver settings, or otherwise manipulating the driver settings so that you're either not using that particular driver, or you're disabling features that might interact in this way. Pete thanks, I dont realy know if this is the case or not, although ive avoided it by using TextureLoader instead. however I do know that runing from the debugger in c# express 2005 seemingly adds a lot to the native-managed transition, this came to light when trying to acces the hi res cpu timer in the debugger this took so long that it was more acurate to use the low res system timer. again this only ocured in the debuger, using ctrl-f5 was fine. relase or debug build gave same results. if its doing a lot of transistions (say one per pixel) then this would explain things. its also managed directx wich is old and abandoned, but as its part of .net 2.0 it does mean its one less library I have to wory about. I have also tried it with the debug directx drivers turned on and i have found no noticble change in performance either way. I have a lot of light map textures to create and I might try and do this on the fly, as it was very slow before, but i was using opengl. Colin =^.^= >> Well after quite a lot of messing about I found that Texture.From... >> is whats making it slow even loading from a memory stream [quoted text clipped - 33 lines] > > Pete
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.