HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


Critical error attempting to replace outer_background

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#104811 (In Topic #20453)
Avatar

Fan in action

My apologies if this isn't the right place to report this, but what is???

Unrelated information: Resized my initial jpg image (cut it from 3MB to 800K in Gimp) converted to a .png

I've replaced the outer_background one time on non-default theme Cincinatti NVC.
after a slight resizing any attempt to resave the image results in:

Code

Critical error - bailing out
This is an error that has been elevated to critical error status because it occurred during the primary error mechanism reporting system itself (possibly due to it occuring within the standard output framework). It may be masking a secondary error that occurred before this, but was never output - if so, it is likely strongly related to this one, thus fixing this will fix the other.
Allowed memory size of 67108864 bytes exhausted (tried to allocate 17088 bytes) [adminzone/pages/modules/admin_themes.php at 1920]

Details here are intended only for the website/system-administrator, not for regular website users.
» If you are a regular website user, please let the website staff deal with this problem.

Depending on the error, and only if the website installation finished, you may need to edit the installation options (the info.php file).

ocProducts maintains full documentation for all procedures and tools. These may be found on the ocPortal website. If you are unable to easily solve this problem, we may be contacted from our website and can help resolve it for you.
Steps to get there:
Admin Zone->Styles->Themes->Manage theme edits for Cincinatti NVC->General->outer_background

I've been careful, I think, to not alter the default template but notice what appears to be a similar report on #1679
Back to the top
 
Posted
Rating:
#104820
Avatar

Attachment
adminzone/pages/modules/admin_themes.php
» Download: admin_themes.php (80 Kb, 109 downloads so far)


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#104821
Avatar

The above should get rid of the error by disabling the memory limit for this case. However, be careful because it's not only the compressed size of images that matter. In this case ocPortal is loading the image up in order to show it's dimensions and failing to load the whole image into memory, but also the users web browser will too to render it.

Let's do some maths, assuming we have 50MB to play with…

sqrt(50*1024*1024)/4 = 1810

i.e. a 1810x1810 image will take 50MB of memory to load. If you have an image of this size (or larger :S) as the background that's quite a lot of overhead.


EDIT: It's not immediately obvious why just 50MB can be a problem, so I'll elaborate. Imagine the user has 10 tabs open, we consider it reasonable for a background to be using 15% of a page's total memory use, and the user imagines their browser using 25% of their system memory.
50*10*(100/15)*(100/25)/1024 = 13GB
So that's 13GB memory use in the user's practical situation, i.e. things really mount up.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#104826
Avatar

Fan in action

First let me say thanks, it does work … and you know there's a "but" coming, right.

One of the images I've been trying to load is 640x427 with "background-size: 100% 100%;" added in global.css
The other two were admittedly quite a bit bigger at 4274x2848 (one a png version of the original jpg) so I see from your math the cause of the failure.  I admittedly don't remember if I ever tried the smaller image after getting the failure from the larger ones.

I've been following along with Jean's "Basic Theme Modifications" and in part 3 he suggests "an image not smaller than 1920 x 1080 px" which is why I had opted for the large rather than the smaller. (I'll add that he does a very nice job - though his line numbers are currently off by about 7 lines :) they're close enough to get me in the neighborhood)

Again, Chris, thanks for the guidance and an excellent product!
Back to the top
 
Posted
Rating:
#104831
Avatar

Community saint

Chris Graham said

The above should get rid of the error by disabling the memory limit for this case. However, be careful because it's not only the compressed size of images that matter. In this case ocPortal is loading the image up in order to show it's dimensions and failing to load the whole image into memory, but also the users web browser will too to render it.

Let's do some maths, assuming we have 50MB to play with…

sqrt(50*1024*1024)/4 = 1810

i.e. a 1810x1810 image will take 50MB of memory to load. If you have an image of this size (or larger :S) as the background that's quite a lot of overhead.


EDIT: It's not immediately obvious why just 50MB can be a problem, so I'll elaborate. Imagine the user has 10 tabs open, we consider it reasonable for a background to be using 15% of a page's total memory use, and the user imagines their browser using 25% of their system memory.
50*10*(100/15)*(100/25)/1024 = 13GB
So that's 13GB memory use in the user's practical situation, i.e. things really mount up.

Chris, effectively, in my "Basic Theme Modifications part 3" tutorial I'm using and recommending a background image of 1920 x 1080 px with a measly size of just 87K.

I am alarmed by your explanation!
I failed to understand that ocPortal's loading the image up in order to show it's dimensions will use up anywhere around 50MB of memory, let alone 13GB when opened in many tabs of the browser.

However, my test, after opening the same site background on ten tabs didn't even register more than 100K dip into my cached, available, and Free physical memory.

I would appreciate If you don't mind, to elaborate on this when you have some free time.

Thanks,

Jean
Back to the top
 
Posted
Rating:
#104832
Avatar

Hi Jean,

I'd have to spend some time to do a scientific test on it, but essentially the browser will have an uncompressed image in memory somewhere (otherwise it would be continually decompressing it, which would severely stress the CPU).

It may be that if it's the same image across multiple tabs (i.e. multiple tabs of the same site), the browser is smart enough to have only a single representation of that image across all tabs. It also is possible that it uploads it to the graphics memory as a surface texture so it doesn't show in the normal process-list memory usage.

In my scenario I'm not talking about one site specifically being slow, but more as a general rule about if all sites did similar things, what would happen to the machine.

Your particular examples would be considered art, so I think the user would make an exception in that case.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#104834
Avatar

Community saint

Chris Graham said

Let's do some maths, assuming we have 50MB to play with…

sqrt(50*1024*1024)/4 = 1810

i.e. a 1810x1810 image will take 50MB of memory to load. If you have an image of this size (or larger :S) as the background that's quite a lot of overhead.
A 1810x1810 image is actually 13.1MB not 50MB.

The correct size for 50MB is 3620x3620, i.e:

sqrt(50*1024*1024/4) = 3620

Chris Graham said

Imagine the user has 10 tabs open, we consider it reasonable for a background to be using 15% of a page's total memory use, and the user imagines their browser using 25% of their system memory.

50*10*(100/15)*(100/25)/1024 = 13GB
I can't see how you came up with that formula.

I could understand either:

50x10x(100/15)/1024 = 3.26GB
or
50x10x(100/25)/1024 = 1.95GB

but not what you have.

Do you have a Samsung Galaxy S / Galaxy S II ? If so, why not check out my ScreenFree FM Radio .
Back to the top
 
Posted
Rating:
#104835
Avatar

Whoops first correction is right, but for second I am assuming many tabs and also many different programs so I'm right there. Regardless I'm just trying to say ram usage multiplies up faster than people may think ;)


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: