Villacaleb / slimdx

Automatically exported from code.google.com/p/slimdx
MIT License
0 stars 0 forks source link

Rendering Issue D3d9 #660

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,

Currently i have ported my video rendering code from Managed Direct to Slim DX.
It seems the video that is being rendered by MDX is smoother than Slim DX.
I have attached a screen shot of it and it is happening in Windows7. In
WinXP the contrast is poor in SlimDX.

Is this an issue with way of rendering done by SlimDX ?

Please help.

Thanks,
Aswin.N.Paranji

Original issue reported on code.google.com by aswin.pa...@gmail.com on 29 Apr 2010 at 1:21

Attachments:

GoogleCodeExporter commented 9 years ago
I can't really tell the difference. Also you're going to need to be far more 
specific
about what you're doing -- we don't support DirectShow so I have no way of 
telling
what you mean by 'video rendering.'

It's quite likely you've simply run afoul of a change in the default settings or
values for some interface or configuration you're working with, which isn't 
really a bug.

Original comment by josh.petrie on 29 Apr 2010 at 5:35

GoogleCodeExporter commented 9 years ago
To be more specific, SlimDX does not "render" anything, we just pass values 
back and
forth between the native and managed code. With very few exceptions, we never 
touch
any of the those values than to marshal them, which I why I believe it's likely 
that
you've simply got different settings somewhere. 

Do note that it's also possible that the underlying native interface changed in 
such
a way as to cause the 'smoothness' differential you're seeing. MDX is built 
against a
much, much older version of the DirectX SDK, whereas SlimDX is built against 
the most
recent release.

Original comment by josh.petrie on 29 Apr 2010 at 5:38

GoogleCodeExporter commented 9 years ago
For comment 1: See the two lines that is crossed on top of 0. the lines are 
smoother 
in MDX when compared to SlimDX which shows jagged edges. I'm not using 
DirectShow to 
render. A D3d9 device is created and a backbuffer is used to draw the decoded 
image 
which is of type YUV. The code which was written in MDX is ported to SlimDX 
with 
little changes to the API parameters as both SlimDX and MDX has similar 
function 
signature for certain API calls.

For comment 2:
You mean to say that the Native API is the cause. if that is the case why am i 
not 
seeing the issue with MDX. Also, how do i get the smoothness using SlimDX.

Original comment by aswin.pa...@gmail.com on 30 Apr 2010 at 4:29

GoogleCodeExporter commented 9 years ago
(1) While MDX and SlimDX have similar signatures, they don't always operate 
exactly the same (as that is not 
our intention). MDX uses classes for some types where SlimDX uses structures, 
and thus the initialization 
semantics would be different (since value types zero-init, SlimDX expects you 
to initialize all fields as you 
would a native structure, et cetera). That's what it is important to know the 
actual details of the technique you 
are using. You have not yet provided those (your most recent description is 
still too vague). A zip file 
containing two compilable projects that demonstrated the differences would be 
most ideal.

(2) I did not say the native is the cause, I said the native API *might be* the 
cause. MDX is several years old 
now, and built against a very different version of DirectX -- one that is 
similarly several years old. SlimDX is 
built against the most recent release of DirectX. Many things have changed in 
the DirectX API in the 
intervening years. It's impossible for us to tell you how to achieve the same 
visual appearance using SlimDX 
without knowing the details of what you are doing to render. You're going to 
have to provide those details, or 
persue the D3D release notes for the last several years to determine the things 
that have changed that could 
impact this (if, indeed, it is related to a native API behavioral change, which 
it may not be).

Original comment by josh.petrie on 30 Apr 2010 at 2:43

GoogleCodeExporter commented 9 years ago
Josh,

i have attached the sample project which demonstrates the difference. This is
happening on a Windows 7 system.

Let me know if you need any other info.

Thanks,
Aswin

Original comment by aswin.pa...@gmail.com on 3 May 2010 at 7:58

Attachments:

GoogleCodeExporter commented 9 years ago
As suspected, you are not filling out the PresentParameters object completely 
(in
particular you do not set the back buffer size). SlimDX and MDX have different
defaults for those values.

Also, your render panels are not the same size (presumably both should be 498, 
425).

Closing, not a bug.

Original comment by josh.petrie on 3 May 2010 at 4:17

GoogleCodeExporter commented 9 years ago

Original comment by josh.petrie on 3 May 2010 at 4:17

GoogleCodeExporter commented 9 years ago
Josh,

Could you please let me know what should the back buffer size be.
 could you please help me  in identifying where i have done the mistake.

Thanks in Advance
Aswin

Original comment by aswin.pa...@gmail.com on 3 May 2010 at 5:06

GoogleCodeExporter commented 9 years ago
It should be set to the size you want to use for the backbuffer. I couldn't 
really
tell you -- I would *guess* that you'd want it to be the same as the pixel 
dimensions
of your render form (498, 425 for the SlimDX one, the MDX one was smaller but 
should
probably be set to the same). But it really depends on what you actually need 
to do
with it. Consult the Direct3D SDK documentation if you need more information 
about
setting up the back buffer.

The properties you need to set are BackBufferWidth and BackBufferHeight on the
present parameters object in your initialization code paths.

Original comment by josh.petrie on 3 May 2010 at 5:10

GoogleCodeExporter commented 9 years ago
Josh,

thanks for providing the information. After setting the width and height of the
backbuffer to the size of Picturebox the jagged edges are not seen.

Thanks,
Aswin.N.Paranji

Original comment by aswin.pa...@gmail.com on 3 May 2010 at 5:37