I'm trying to show image files (jpg, png, gif) that can be larger than the available display area. I've embedded an Image inside a cCanvas (to get scrolling), but the large images are not completely displayed.
Very large images (e.g. 2480 x 3507) have the top or the top and bottom of the image clipped withing the scrolling Image.
What is the largest graphic one can display using the mx.controls.Image ?
Thanks
The 2880 pixels limit is for BitmapDatas, for DisplayObjects there's a limit of 8191 pixels.
You can bypass these limits by using the BitmapDataUnlimited-class available here: http://code.google.com/p/bitmapdataunlimited/
However, if performance is important I'd recommend letting such large images consist of multiple smaller ones instead. Even if you don't reuse these smaller ones or take care of removing them from the displayList or setting their visible-property to false there will still be a performance gain as flash automatically detects that they're outside of the stage and wont have to be rendered.
Edit:
I forgot saying that the 2880px-limit only applies when manually creating BitmapDatas, images bigger than that can still be loaded in, and their BitmapDatas (which are bigger than 2880px) can be accessed and manipulated.
You could easily have a Bitmap with a bitmapData as large as the viewport, then you can set its bitmapData by doing something like:
viewportBitmapData.copyPixels(sourceBitmapData, new Rectangle(x,y,viewportWidth, viewPortHeight), new Point(0,0))
When scrolling, you could simply do the above on each frame
Or if performance is important, you can when scrolling (if scrollingDistance is less than viewportSize) use viewportBitmapData.scroll(x,y) to shift the whole bitmapData, and then copy only the new pixels.
I've read that the limit is 2880 pixels per dimension in Flash 9. In Flash 10 the limit is higher. Check to see which version you're compiling for.
You could potentially chop the image into smaller pieces and assemble them in Flex.
If makes a difference which FlashPlayer you are targetting:
versions VS maximum bitmapsize
flashplayer -9 : 2880x2880 px
flashplayer 10 : 4096x4096 px
flashplayer 11 : unlimited
Related
I resize a floating window, let's say to some size WxH pixels. Then I change to tiling mode, so the window gets resized automatically to some new size, let's say W'xH' pixels. Now suppose I switch the window back to floating mode.
What I Want: The window automatically resizes to the last size, i.e., WxH.
Current Situation: The window just becomes floating, but still has the size W'xH'.
Is there any way of making this happen? Like some way we can save the dimenisons of a window everytime it's resized, and whenever a window enters floating mode, apply the last known size from that application?
I know it probably sounds very dumb, I'm so sorry.
There is multiple ways. The "simple" way is to use client.connect("property::floating", function(c) if c.floating then restore(c) else save(c) end) where you implement both save and restore yourself by calling c:geometry().
The more advanced way would be to use request::geometry and awful.placement built-in geometry memento support. That's preferred since it allows to prevent the client from flickering between 2 sizes. However it is much more complicated to pull off.
You can use awesome-remember-geometry from berlam.
https://github.com/berlam/awesome-remember-geometry
I have a sprite sheet that i use as div background . The dimensions are :
Width: 105920
Height: 240 .
It's a monochrome png file with size of 620kb , so i assume size is not the problem here .
When i try to use it as a background-image: url("spritesheet.png"); Firefox throws an error saying "Image corrupt or truncated" . Chrome does not show any error message , but the image is not shown .
If i resize the width of the image with gimp to 10,000 , everything is ok . but obviously i cannot use it as intended any more .
Are there any restrictions for maximum allowed image size in CSS ? Am i doing something wrong ?
According to the answer to this question, your image is too big for Safari/iOS to handle. Other browsers probably have similar limitations, as you have found with Firefox. The file-size of 620kb is acceptable, but the dimensions of the image (over 25million pixels) is a little too much to handle.
That said, even if browsers could show your image, I would very strongly advise against using an image of those dimensions. One uses sprites for performance reasons, but an image that size will incur a massive performance penalty... you'd be shooting yourself in the foot.
Not a solution to your problem, merely a comment. The advantages of using sprite-sheets may be lost or much reduced when you orient them horizontally. This causes a problem with cache-misses.
Imagine you had a 10x10 pix sprite. To load the portion of the your image that contains it, you need to load (numPixels = sprite_height * src_width).
In your case, this would be 10 x 105920 pixels = 1,059,200 pixels! - Just to cache 100 pixels worth of image.
The best way to orient a sprite sheet is vertically. You use the same equation to determine the number of pixels that must be loaded, but get a very different result. A result that is now small enough to fit in the small(est), fast(est) cache.
In this case: 10 x 240 pixels = 2400 pixels. - Again, overkill for just 100 pixels, but a superior solution than the previous example gives.
Changing the orientation of the sheet from horizontal to vertical results in a reduction of the size of the memory needed to cache this sprite of 441 times. Not exactly something I would characterize as insignificant.
The effect of making this change will be most apparent when repeatedly drawing the same sprite or sprites that are located near to one another in the sprite-sheet.
Given that the browser works with tru-colour images on the screen, it doesn't seem unreasonable to think that for performance reasons, the browser would convert your monochrome image to one compatible with the remainder of the display - one that has 24 bits/pixel, albeit with (relatively) little variation in value.
If indeed the image was converted to 24bit, well, the memory requirements would be huge
105920 * 240 * 3 = 76262400bytes. Yes!! That's 72.73 megabytes!! Add another 1/3 if its converted to an rgba(32 bit) image.
So, I've got two suggestions.
Orient your images vertically
Use several sprite sheets.
Let me start off by stating that I realize the arguments against doing CSS Sprites for large images. I even asked a question about why that could be considered a bad idea (and added an answer of my own). Now that we've had that talk...
I'm going to be making a large CSS Sprite-map. For the process of making this sprite-map, it behooves me to know what (if any) limit exists for the height and/or width of a sprite image in order for browsers to properly process it.
The ultimate reason behind this question is a debate over whether to lay out the sprite images in a grid or in a single row/column. For example: is it necessary or beneficial to do 4000 x 3000 instead of 400 x 30000?
Edit: The sticking point here isn't about what size images can be, but rather what size browsers can process for sprites. Given the lack of detail thus far, I'm moving forward with generating the single-large-column sprite. I'll post details of my experiences as an answer once that is complete.
Sometimes it's more of a matter of download time. Since browsers can use multiple connections to download files, a huge image can take longer to download than a few smaller ones.
If your image is so big that it's slowing down page load maybe it's time to consider several smaller sprite images.
Direct-X 9 has a size limit if 4096 pixels, so any Internet Explorer filters applied to these elements will crop them at 4096 pixels.
See: IE display transparency bug on height > 4096px?
In practice, this seems to work with no problems in Firefox 5+, Chrome, and IE7+ for a sprite image of 400x16560.
The potential issues of IE's directx rendering engine failing on images over 4096px do not create problems in IE7 or beyond; we have no method or need to test IE6 for our current project.
The one place that we experienced problems with really large spritemaps is on mobile platforms. Android devices handle them reasonably well, but iOS devices break down pretty badly, and in a strange way: They shrink the image down to fit within the dimensions they accept. So our CSS works perfectly for a small spritemap, but with no changes except increasing the physical dimensions of the spritemap image, the sprited images begin to show four times as much of the spritemap in the same html entity, with exactly the same CSS.
There is a limit in version 1.0 that is upgraded in v1.1 But still there is a limit for dimensions:
In accord with version 1.1, the scope of the 31-bit limit on chunk
lengths and image dimensions has been extended to apply to all
four-byte unsigned integers. The value -231 is not allowed in signed
integers.
Source
A funny limit is IE6.0 fails to display PNG images of 4097 or 4098 bytes in size!
But these limits are very huge in compare to what we're using in web pages.
i have a 100x100px image and i need to show that in 3 different dimensions in html,
50x50 60x60 70x70
so my dubt is if better to save img in 3 dimensions then do not use css or html width and height or if to use same img with css rules about dimensions... which solution is faster rendered ?
It depends.
If you are using the same image, Only 1 time image cache is required by the browser. So If you are displaying more than 1 type of image in the same page then dont go for multiple images. Otherwise go for multiple images.
But honestly, 100x100 if you have, It should not be a problem to load. Only in slow connections it will be problem (<128kbps). Otherwise i dont see a considerable difference.
I wouldn't worry too much about rendering speed, the main difference you'll see is in terms of image quality. Some browsers (Chrome) perform very high quality image interpolation, while others (IE, Firefox) opt for a faster algorithm that does not give as nice of a result. So you'll get the best, most consistent image quality by having the three separate image files, one for each size.
That said, since you're only scaling from 100x100 to a minimum size of 50x50 you probably don't need to worry too much about interpolation artifacts either. So I'd recommend just doing whatever is most convenient for you to implement.
And in terms of pure rendering speed, having the separate images will be faster, because no interpolation step is required in that case. In terms of initial page-load speed, however, having a single image will be faster, because there is only 1 file to download instead of 3 (or 4). As for using CSS or HTML tag attributes to set the width and height, there will be practically no difference in speed. The expensive operation is the interpolation of the image itself, and it doesn't make much difference if you specify the interpolation through CSS or through tag attributes.
I am attempting to capture a very large image that was made dynamically within the Flash Player (the size of the image is 2400px by 12,000px) and am running into some very serious issues... Let me run down how the image get's to that size in the first place:
User adds elements to a canvas and then when the user is finished the canvas scales up to 2400px wide and ~12,000px tall. The problem arises when I attempt to save the image to the hard drive. Now, I dont know if this will affect the recommended fix, but the rendered image wont be saved on the hard drive, it will be sent to a server. I know about the ~4050px limit in Flash Player and was thinking I could get around that by clipping the images with the ImageSnapshot.captureBitmapData() method and keeping the required Rectangle variable below 4000px then repeat that down the large image until it reaches the end where the final images will be pieced together at a later time. However... As i mentioned the error comes when it reaches the 'fileReference.save(pngImage);' method... Has anyone else done something like this?
Have you tried if fileReference.save works at all (e.g. with smaller images like 100 px height)? It seems that the image data will perhaps be transformed to string data, so there might be other limits you're not aware of at the moment (your uncompressed image data will be around 86 MB, so even a PNG file with good compression might be around 10 MB in size, at the moment you're trying to save a third of this, but 3 MB still is quite large).