Re: off screen plain
- From: "GrkEngineer" <GrkEngineer@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 12 May 2005 06:01:01 -0700
Thank you sooooo much for your help. I'll have to look into using a memory
stream for my data. To describe a little more, I'm receiving a 1024x1 chunk
of data every 18ms. I want to display this data as a waterfall display. So I
created a surface (soon to maybe be a memory stream) of 1024x14000. I also
created a default texture of 1024x1024 to display a portion of the offscreen
surface. I'm using device.updatesurface and sprite.draw2d for that function.
The problem was locking the large surface. I was only locking a single line
at a time as it came in so there was no overlap, but as you well know the
reset wouldn't let me lock the texture anymore. I'm fine letting the display
go black during resize, but I need the data stored. Thank you soo much. I'll
give you an update. Actually had to switch to navite win32 and DrawDibDraw
for the speed and ease of use.
GrkEngineer
"Patrice Scribe" wrote:
> BTW it's left you with the other possibility. You could try something like :
> - create a back buffer that is sized to a "full screen size" and use only
> the relevant portion
> - cancel the Resizing event so that MDX doesn't try to reset the device
>
> This way it should suppress the "reset while resizing" issue. You may
> encounter though other scenario that would still make a device loss (such as
> running a screensaver).
>
> Good luck.
>
> --
> Patrice
>
> "Patrice Scribe" <@> a écrit dans le message de
> news:uhGwTsuVFHA.1200@xxxxxxxxxxxxxxxxxxxxxxx
> > It looks like it doesn't work :
> > - I created a system (also tried with scratch surface). In my main loop I
> > read the first bytes...
> > - During the DeviceLost event I tried to write down to the surface
> > - I try to resize the window, it crashes
> > - To make sure I moved the writing code in the main loop and it works...(I
> > read back the value I've just written so the writing code looks to work).
> >
> > For now I would say that when the device lost even locking system or
> scratch
> > resources doesn't work...
> >
> > It looks like you'll have to write down these data somewhere else such as
> a
> > memory stream so that you can use them once the device is recovered...
> Looks
> > like quite tought. What if the device is lost for sometime. It looks like
> > you are receving data at quite a high speed ??? Make me think about a
> > streaming video or something similar though I don't see what the user will
> > do with the data he missed especially if you keep receiving new data...
> >
> > You still may want to try something similar in case I missed something...
> >
> > --
> > Patrice
> >
> >
> > "Patrice Scribe" <@> a écrit dans le message de
> > news:%23%23HcxatVFHA.2768@xxxxxxxxxxxxxxxxxxxxxxx
> > > I don't remember to have seen something explicit about that. Your best
> bet
> > > is likely to do a quick test (create a system surface and try to fill
> this
> > > surface when the device is lost). My guess would be that it should
> > logically
> > > be allowed (but they might have blocked this scenario for simplicity
> > perhaps
> > > ?)
> > >
> > > The resizing automatically reset the device to adjust the backbuffer
> size.
> > > My understanding is that you'll still have to dispose/recreate video
> > memory
> > > resources likely in the DeviceLost/DeviceReset events... (not a big
> change
> > > but gib enough to destroy the hardware state).
> > >
> > > In the past I saw that some guys are creating a wide backbuffer and are
> > > using only a part of it. Doing so makes reset while resizing useless as
> > your
> > > back buffer is already big enough (trading a bit of memory). I don't
> know
> > if
> > > can do that in Managed code...
> > >
> > > I'm doing currently some experiments about lost devices. IMO this is an
> > area
> > > where the doc lack some details...
> > >
> > > --
> > > Patrice
> > >
> > >
> > > "GrkEngineer" <GrkEngineer@xxxxxxxxxxxxxxxxxxxxxxxxx> a écrit dans le
> > > message de news:A1573912-475C-414A-93B0-A5478B2745C0@xxxxxxxxxxxxxxxx
> > > > Hehe, just to clarify my last post. I'm not doing a device reset on
> > > purpose.
> > > > It happens when the form is resized. How do I properly handle this. Do
> I
> > > need
> > > > to do anything in the Form's Resize event? Maybe the Resize begin and
> > end
> > > > events? My question still remains. Can I lock a surface with
> > > > Pool::SystemMemory while the device is reseting or resizing? What
> about
> > > > Pool::Scratch? Thanks
> > > >
> > > > "GrkEngineer" wrote:
> > > >
> > > > > I'm receiving data from a UDP port at 55 Hz and displaying the data
> to
> > > the
> > > > > screen. I've created an off screen plain surface to copy the data to
> > > using
> > > > > either system memory or scratch memory. My problem arises when I try
> > to
> > > do a
> > > > > device reset. The surface becomes disposed. Can I not access the
> > surface
> > > is
> > > > > RAM while the device is in a lost state? This would be horrible for
> my
> > > app. I
> > > > > need to constantly save the data received.
> > > > >
> > > > > Nick Nezis
> > >
> > >
> >
> >
>
>
>
.
- References:
- off screen plain
- From: GrkEngineer
- RE: off screen plain
- From: GrkEngineer
- off screen plain
- Prev by Date: RE: off screen plain
- Next by Date: Re: MDX with VS2005 Beta2
- Previous by thread: RE: off screen plain
- Next by thread: CPU performance rises when I'm opening an other application/dialog
- Index(es):
Relevant Pages
|
