|
You can pass them to a web browser control and see which ones break, I guess.
Christian Graus - C++ MVP
'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
|
|
|
|
|
Sakthiu wrote: I need to find broken links in a html file. Which is the best way to find it out?.
Find Broken links in a Web Page[^]
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
Hi,
can anybody tell how to find the bandwidth of the network as well as speed of the network in pure vc++ 6.0 programming?
Any links related to this are welcome.
Thanx in Advance
regards
Nitin
|
|
|
|
|
I wanted to display a compressed movie using Visual C++ at 25fps. I have the decompression working properly and display is also fine. But the movie is not smooth and not fast enough to be 25fps. I am using CDC structure to paint the processed pixels. What should be done to display efficiently. Should i go to kernel level calls. If so how can i do it. Or is there any ready-made techniques available in Visual C++ to do it.
Hoping for a reply from graphics experts at the earliest
|
|
|
|
|
DirectX is really the way to go if you want to do animation that smooth. of course, DirectShow will already do it for you, if it's a known codec/format.
Christian Graus - C++ MVP
'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
|
|
|
|
|
Its not any format. Its just RGB pixel values available as an array of 352X288(CIF) size. I would like this display to occur without being much disturbed by the decompression algorithm which is computatinally intensive. can i do something like dispatching a command and getting it done by an AGP or some solution similar to that.
|
|
|
|
|
jossion wrote: Its just RGB pixel values
OK, then it's not compressed, right ?
I'd create a DIBSection of this size, use memcpy to copy the rows into place, and then display the bitmap from there, but probably using DirectDraw.
Writing direct to AGP is outside of my experience.
Christian Graus - C++ MVP
'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
|
|
|
|
|
If you can't decompress the frames fast enough then no rendering system is going to help.
Using GDI it's possible to render many many 352X288 videos at 30fps using very little CPU - I do
it all the time.
You have to have the data ready (uncompressed) to be rendered though.
I think Christian mentioned a DIBSection, which will allow you to have a buffer to jam your
uncompressed frame data into and quickly blt to the screen.
You can go the DirectX route but I would bet you won't notice a performance increase since 25fps
is easily doable by either GDI or DirectX.
Mark
|
|
|
|
|
First of all let me thank Christian and Mark for the valuable suggestions shared. I feel that I will have to do some homework before I could understand what you have suggested since I am new to this area. For the same reason I would like to get some links to resources which may help me to start with in this field (like programming DirectX or GDI).
My decompression is fast enough for a frame rate of 50fps. The problem is with display only. Moreover I have written the display and decompression in a serial manner. First I think i will have to multithread it and then go for GDI or DirectX.
I would like to get more help from Mark regarding GDI if the problem mentioned above could easily be done with GDI.
Thanking in advance.
|
|
|
|
|
The DirectShow SDK and the Windows Media Format SDK may be helpful resources. Even though
you have your own codec and you don't need to use those SDKs there may be some helpful
hints on how Microsoft does it.
Typically...
There's two areas that can be dealt with separately - I/O/Uncompress and rendering.
I/O and uncompress is reading the source data and uncompressing into individual video frames.
Using some kind of buffer allocator scheme, the decompressor allocates a frame buffer, writes
the uncompressed frame data to the buffer, and queues it for rendering.
The renderer checks the frame buffer queue. If there is a buffer available it checks the time
stamp. If it's not time to display the frame yet then it waits. If the time for the frame has
passed then the frame is either rendered immediately or discarded.
That's the typical scenario using the SDKs I mentioned above.
To implement it, there's all kinds of possibilities. For human-viewed video, frame rates don't
need to be beyond 30fps so you don't have to get too crazy with timing issues.
It's possible to do both steps on one thread but the performance can be bad. You decompress
a frame and then wait until it's time to render it. This relatively large gap in time of
doing nothing could be used to decompress another frame and have it ready.
A more elegant solution would be to use two threads. One thread reads and uncompresses frames.
It does so until enough frames are queued (some pre-defined read-ahead value) then pauses.
On another thread you could render the frames. This thread could wait on an event like a
multimedia timer event set to the frame rate or be triggerred by an event from the
decompressor thread (set every time it adds a frame to the queue perhaps).
There's some things that can make the process more efficient...
1)Pre allocate a pool of buffers so they don't have to be allocated every
time you need one. Typically you'd want enough buffers to hold the read-ahead amount of frames
mentioned above. You could actually use this to control the uncompress thread - when the
thread tries to obtain a buffer from the pool and there's none available then it waits.
2)Design the buffers to be in a format ready for rendering. If the buffers are alread DIB
sections for instance, then as soon as the frame data is uncompressed to the buffer then it's
ready to render. No second copy is necessary. For Direct3D (formerly DirectDraw) the buffers
could be Direct3D surfaces.
3) Don't do any of this on the app's main/UI thread. That way the user interface stays
responsive while the video plays.
I hope this gives you a few helpful tips to get you started.
Mark
|
|
|
|
|
Thanks a lot for the detailed suggestions. I will be back after a detailed study of those.
|
|
|
|
|
some text tell me that: allocate a Global memory, then give it to clipboard.
But I want to know: who/how/when free clipboard's memory?
Maybe EmptyClipboard()? I am not sure.
anyone can help me?
|
|
|
|
|
DollfaceYY wrote: But I want to know: who/how/when free clipboard's memory?
Got this from MSDN...
To place information on the clipboard, a window first clears any previous clipboard content by using the <code>EmptyClipboard </code>function. This function sends the <code>WM_DESTROYCLIPBOARD </code>message to the previous clipboard owner,<code> frees resources associated with data on the clipboard,</code> and assigns clipboard ownership to the window that has the clipboard open.
|
|
|
|
|
Does it matter where I define a variable? For example, take the following two cases. Does one result in more efficient execution code than the other? Variable x is defined in differnt places. Are there any general guidlines for this? Thanks.
CASE 1
int x = 0;<br />
for(int i = 0; i< 10; i++)<br />
{<br />
x = a + b + c;<br />
}
CASE 2
for(int i = 0; i< 10; i++)<br />
{<br />
int x = a + b + c;<br />
}
|
|
|
|
|
Case 2 defines it over and over. I've been told this can be *more* efficient, I suspect otherwise. The truth is, that sort of optimisation is rarely going to give you visible benefits
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: The truth is, that sort of optimisation is rarely going to give you visible benefits
Anytime you can optimize the better, I say. The compiler may or may not optimize it, why take the chance. Like Christian said, it probably won't matter in most sutuations, but if you're looping through a million rows it will.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
When the variable doesn't have a ctor or a dtor (as in this case) it makes no difference in release mode - the optimizer will alloc space for the variable on the stack once. In debug builds, x will be reset to 0xCCCCCCCC every time through the loop, but speed isn't a concern in debug mode.
|
|
|
|
|
I always try to define a variable like that only one time (outside the loop). It shouldn't make a difference unless it's a more complex type that has a lengthy constructor/destructor. I'm old, and set in my ways.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi.
Using Visual C++ 6, can i include controls like edit box to SDI application without the use of dialog?
|
|
|
|
|
Yes, sort of. You derive your window from formview, and it essentially becomes a dialog with a template. There's also no reason you can't just add controls dynamically to any view type you like
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
UnknownBlue wrote: Using Visual C++ 6, can i include controls like edit box to SDI application without the use of dialog?
Yes, CFormView should help you, but then it takes a dialog resource.
Another option is to directly create controls using their create method.
|
|
|
|
|
Can you use of CFormView ?
|
|
|
|
|
We have an SDI application that we'd like to be able to shrink up to just a small height (approx 60 pixals of client height). I've got the code to shrink it and expand it back to the original size. Unfortunately, when it's shrunk down, the framework makes the actual size much larger and adds in vertical scrollbars.
Anyone know how I can remove the scrollbars when they are added in automatically?
|
|
|
|
|
You could try and remove the WS_VSCROLL window style in PreCreateWindow.
The CREATESTRUCT structure has a style member from which to remove this style.
cs.style &= (~WS_VSCROLL)
« Superman »
|
|
|
|
|
Good idea, but it doesn't seem to have any affect. I also tried
cs.dwExStyle &= (~WS_EX_RIGHTSCROLLBAR);
It didn't work either. Seems like the document interface has some limit on the minimum size of the document window.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
