From the javadoc of FileEncodedImageAsync I didn't understand two things:
Does the placeholder have an impact on RAM or is it immediately destroyed completely as soon as the image is displayed?
Can the placeholder have any size or must it have the exact same size as the image saved on file, i.e. the one to be displayed?
Placeholder should be global and should be an image that's efficient otherwise it will thrash ram. Since it's global it doesn't matter that it takes RAM.
It must have the exact same size since it needs to occupy the same space. That's why most apps of infinite scroll type standardize the size of the image view area.
Related
Is there a way to set the minimum size of a component instead of just the preferred size?
I am currently setting the preferred size by overriding the calcPreferredSize method on the component, but the layout shrinks it to an unknown minimum regardless of the preferred size during certain scenarios.
I am using code, not the UI builder.
No, we don't have a way to do that.
We didn't copy the minimum/maximum concepts from AWT/Swing since those never made sense there either and were used in different ways by the layouts. If a component is in a situation where it can't fit we have a problem regardless of the minimum value. You need to place it in a scrollable Y container or give it more space.
Preferred size is a hint the eventual determination of size is done by the layout manager logic.
If you have a specific example of something that misbehaves in terms of layout I'd be happy to help with that.
I'm working on a small text editor in ncurses with the purpose of learning more about the library. One of the first challenges was implementing a proper scrollable text buffer, retaining the editing abilities. I've created a cursor struct, containing the screen coordinates and the buffer coordinates. When you move the cursor, the x and y are constrained to the LINES and COLS max values. The buffer coordinates, however, are constrainted to the limits of the text file (size and linesize).
This works well, but i was wondering if there's a better way of doing this. Right now, every cursor movement operation results in modifications to both coordinate systems. Maybe there's a way of converting between coordinates and keep just one (the buffer one, preferably)?
Have you tried using a pad? As a window can be no larger than the terminal itself, else data is lost when if passes over the edge boundary. A pad is used to allow for larger data display by the use of newpad. The pad can be any length the system memory has available; viewed by way of a window subpad which displays the contents of the pad at a specified location.
In my application I have an area in the main window that at any time can contain one of several different controls.
This controls are generated at runtime and their contents can vary depending on underlying data, so I do not know beforehand how much space they'll take up.
What I want to know is: is there a way to determine at runtime how much space a control needs in order not to be "cut off" or need a scroll? ie: how much space does it need to be COMPLETELY visible?
I tried the "DesiredSize" property and it kinda works, but not always: if the control has been used already (it has already a size) it returns it's last used size rather than the correct one, even if I call "InvalidateMeasure()".
Any ideas??
Call Measure on the control. Give it infinite space as the available size for the calculation. Then check the DesiredSize to get the needed width (and/or height).
I have textBlock defined such that it fills the entire screen of the phone.
The textBlock is initialized with some data which cannot be displayed in the boundary and hence gets clipped.
I want to read the data which actually got rendered on the screen (i.e. whole data - clipped data).
Putting a breakpoint shows me that myNewTextBlock.Text contains the entire data that it was initialized with.
Thanks
You could look at using Measure and MeasureOverride to determine how much of the Text would fit in the available space.
You'll likely need to test various trimmed versions of the Text but it shouldn't be too tricky.
I am writing a text renderer for an OpenGL application. Size, colour, font face, and anti-aliasing can be twiddled at run time (and so multiple font faces can appear on the screen at once). There are too many combinations to allocate one texture to each combination of string and attributes. However, only a small subset of the entire database of strings will be on the screen at any given time.
This leads me into the opportunity to create a cache for the strings that are being printed frame after frame. It has been mandated that I use only one texture for the entire operation, as creating a cache of many textures would incur a texture swapping penalty for every different string printed from the cache.
So I have before me a 2048x2048 texture, into which I can place whatever strings I can fit as they are being requested by the application for caching purposes. I have quickly realized that tracking the free space available in a two dimensional space is not trivial.
I have been looking at things like Best Fit and Next fit, but those seem to be suitable for 1d spaces.
How can I manage this cache texture in OpenGL?
Edit: I have since learned that this is an instance of a "2d packing problem".
What you have is the bin-packing problem.
Bad news first: It's NP-hard, so it's worth to find the optimal solution.
I've done such texture-caching for fonts as well. I didn't cached entire words but just the glyph images. That makes things a lot easier because all your images are roughly square-shaped. A simple grid based approach to keep track of the texture-memory worked pretty good.
In case I got glyphs that are larger than one of my grid-boxes I just allocated two or more boxes using brute force search (it didn't happend that often). In case I didn't found any suitable block I just randomly removed some glyphs from the cache to make free space.
That was much easier than keeping things in a last recently used cache and performed nearly as good.
Btw - you will always have some waste on texture memory for such a cache. Unless you're very tight on memory that shouldn't be a problem. You should use a small texture-format (8 bit alpha works well for fonts).
Also: If you make your grid-blocks a multiple of 8 pixels, and you can drop your antialiasing to 4 bits you can compress the glyphs into one of the compressed DXT or S3TC formats on the fly. The wasted texture-space becomes a non-issue that way.
If you are short on texture memory you could take a look at "Distance Field" or "Signed Distance Field" font rendering technique. You could use 512x512 texture per font family and you could render perfectly antialiased text of any size.
For that algorithm you need to generate a special texture, which contains distance from the texel to the edge of the texture. Take a look at original paper by Valve guys: http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf . There are some frameworks which utilize this. For instance latest version of Qt uses signed distance field for text rendering.
I have opted to use a simple approach. Divide the texture into variable height rows. The first texture to be placed in a row decides the height of the row. If a texture can fit into an existing row by height, check to see if there is enough width remaining and place it there. Otherwise start a new row. If a new row cannot be started, do not cache the string.