I had some issues in full-screen mode using OverlayContainer.
The solution is to use FullscreenOverlayContainer (which also works in full-screen mode)
The FullscreenOverlayContainer is an alternative to OverlayContainer that supports correct displaying of overlay elements in fullscreen mode.
Now, I wonder why OverlayContainer exists at all:
Are there any drawbacks in using FullscreenOverlayContainer?
In which situations would we use OverlayContainer instead of FullscreenOverlayContainer?
see comment in #19434
original reasoning was that handling full-screen mode was extra code that not everyone necessarily needed
So when you want to save some extra bytes and really don't need full-scrren you may use OverlayContainer.
My take on this is to always use FullscreenOverlayContainer.
Related
Whenever I try to make a game or something that requires the rapid clearing of a screen, I've used system("CLS"). I now know that that is not good to use so I tried using a for loop to print new lines rapidly. While this works it looks really weird and less clear. I've seen people try to use STRING to clear a screen but whenever I try it it never works. How can I clear my screen efficiently and cleanly.
There's no standard way to clear the screen. But in any case, actually clearing the terminal and redrawing will be far too slow and glitchy for many games.
You should use either your OS's native terminal handling functions, or a cross-platform library that abstracts them.
I'd recommend ncurses, which is the latter. It basically provides an interface akin to a double-buffered graphics API, and handles all of the actual terminal twiddling so the frame swap is as fast as possible.
We've encountered a strange problem on newer laptops using built-in graphic cards.
In order to draw true-type fonts we obtain the glyph outlines using wglUseFontOutlines and then draw them with in glRenderMode(GL_FEEDBACK).
Afterwards we parse the feedback buffer. This has worked for many years.
Now we have a problem with glyphs containing holes (only on platforms with built-in graphic cards):
wglUseFontOutlines works perfectly. If we just draw the returned display lists, everything is fine. However, the token stream generated with GL_FEEDBACK is corrupt. The debugger shows nothing unusual, all functions return with success and the parsing itself works fine too. It is really the binary data generated by GL_FEEDBACK mode, which is wrong.
Has anyone else encountered this problem?
And is there an alternative way to obtain outlines and fillings for true type fonts on Windows?
I'm just guessing into the blue here: The GL_SELECT and GL_FEEDBACK rendering modes were usually not supported by widespread GPU driver OpenGL implementations. Only a handful graphics cards from the previous century actually did support these rendering modes. Hence you would almost always fall back into a software implementation when using those modes.
However given modern GPU's vastly more flexible feedback mechanisms, the latest drivers could actually try to implement those rendering modes using GPU features (somewhat weird, because those modi have been removed from modern OpenGL profiles). Anyway, this could be the reason why you're experiencing these problems.
In order to draw true-type fonts we obtain the glyph outlines using wglUseFontOutlines and then draw them with in glRenderMode(GL_FEEDBACK). Afterwards we parse the feedback buffer.
That's a cool Rube-Goldberg machine. Why don't you simply cut the middleman and obtain the glyph outlines directly using the appropriate Windows GDI functions (GetGlyphOutline) for this? This is what wglUseFontOutlines is using internally anyway.
I have a point-of-sale application written in Perl/Tk. I use X11::GUITest to do automated testing of it, driving the app via hot-keys bound to the buttons and other widgets (it's normally touch-screen driven). However, X11::GUITest doesn't have a way to "read" text back from the screen, so I resort to augmenting the app to write temp files as well as putting data on the screen. The test scripts then look at the temp files, not the GUI. But I'd love to extend X11::GUITest or make a new CPAN module that can scrape text strings from X11 GUIs. I'm not after graphics-to-text conversion; it's my (faint) understanding that somewhere in the depths of the X window system, label text and such are stored as text strings and rendered to bitmap form late in the pipeline (?).
Anyone have guidance on how to do this, or pointers on where to start?
Yeah, I know I should've adhered to better MVC separation and not actually test at the GUI level, but just below it; however reality got in the way and it is what it is!
The best way to do this is to make your program work with an accessibility framework like ATK (used in GTK applications) and then use that to query for the strings as a screen reader would have to for text-to-speech translation. This is the approach taken by the Linux Desktop Testing Project and dogtail testing frameworks. You get the bonus of using existing, well tested code and making your application more usable by disabled users (as may be required by laws such as the Americans with Disabilities Act in the US and similar laws in many other countries).
If your application is using modern font frameworks, like libXft2, this may be your only choice, as those strings are only in the client application, not the X server, and the character to pixmap conversion is done in the client. (If your text is antialiased, it must be using these instead of the legacy X11 API's.)
Even with the legacy X11 API's though, the X server doesn't store the strings once the text to bitmap conversion is done, so there's no good way to query them short of intercepting them in that case.
The program listres lists resources in widgets, including label texts and I think the contents of text entry boxes. You may be able to use its output directly, extracting what you need, or you may need to look at the source and see how it's done.
Im trying to write an ascii game for an assignment. The program must be written entirely in c, no c++.
How can i get the program to open a window capable of rendering ascii art? I want to create a window of a certain size, that is capable of printing in multiple colors. A simple console window is insufficient.
Also, on a related note, can anyone show me a function that will write directly to the buffer? printf is too slow, and doesnt seem to be versatile enough for the graphics i want to produce.
Any help will be greatly appreciated.
Thanks in advance.
A simple console window is insufficient.
I disagree. A console window is perfectly fine for anything you seem to want to do. Colours, full ascii range, highlighting...
Also, on a related note, can anyone show me a function that will write directly to the buffer? printf is too slow,
How fast do you need to write? If you're forming the strings yourself and calling printf, it essentially just copies it into the buffer for you.
try ncurses
altho i dont think it works for windows at this time (v5.7)
or even AAlib
You want the Windows Console API there are functions in there to do exactly what you are asking. For example use SetConsoleDisplayMode to change the console size.
See here: http://code.google.com/p/ie7-js/
Does anyone have any experience or remarks about this javascript? Is it worth including? Do you recommend it?
I know many people, myself included that are using various IE hacks to get transparent PNG support. THis looks like a little bit more help, and as long as it works, and the size is fairly small, I wouldn't see much against using it.
I've used it before, and my results are mixed. Those scripts cause IE to churn for a bit on page load. Basically, you have to think of it as iterating through Elements and stylesheet rules to apply "fixes" for areas that are deficient in that particular rendering engine. In some cases, depending on how complicated your markup or stylesheets are, that can take a bit of time and you will see the browser hang.
That said, if you can trade off that performance cost, you will save development time as you'll spend less time hacking around IE6 quirks; IE7/IE8 will provide enough missing functionality that you can avoid certain edge cases, can develop using standards better (min-width/min-height, multiple className selectors, etc.), and certain rendering issues will disappear.
However, if you just need 24-bit transparent PNG support, use a tool built for that. Including IE7/IE8.js for PNG support alone is like pounding in a nail with a tank. Use DD_belatedPNG for that.
It works, but its worth keeping in mind that ie7.js and ie8.js do much more than provide transparent PNG support. Even with the transparent PNG support, its worth keeping in mind that transparent background images cannot be tiled (repeated) using background-repeat or positioned using background-position. This hinders any ability to use CSS rollovers using background-position. I've only used it on one site I've done, and now that I'm updating the site I can't remove the ie8.js because if I do the entire website breaks layout in IE. I don't believe I'll be using it in the future, and instead rely on simple CSS hacks or simply allow my sites to "degrade gracefully" in IE6.
I know that there are some tools for fixing the transparent PNG problem which are more flexible than this. For instance, the jQuery plugin ifixpng2 will support background position, which ie7-js doesn't do.
As long as you are aware of exactly what it fixes, I would say go for it. I'm not sure about this lib exactly, but some libs get very expensive if you have a large DOM, as they tend to hook in HTC file base behaviors on EVERY DOM Element. This causes the dreaded "Loading x of y" status bar message to flash constantly on the initial load, and any newly generated DOM content.
well its beautiful and works grate way u can use cs3 features like li:hover. we did lost of project last time using ie8.js and it works great way.