On Mon, 12 May 2008 06:12:28 -0700, colin <co*********@ntworld.NOSPAM.com>
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