Texture.FromBitmap is slow runing from debugger
colin
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 =^.^=
Peter Duniho
wrote:
> 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
> !
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
colin
news:op.uaz8n...@petes-computer.local...
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 =^.^=
Peter Duniho
wrote:
> 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
colin
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 =^.^=
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 =^.^=
"Peter Duniho" <NpOeS...@nnowslpianmk.com> wrote in message
news:op.ua0jd...@petes-computer.local...
Peter Duniho
wrote:
>
> 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.
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
colin
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 =^.^=
"Peter Duniho" <NpOeS...@nnowslpianmk.com> wrote in message
news:op.ua184...@petes-computer.local...