This is a simple example to demonstrate how to easily trim the areas off the image and only display the parts where the object lies. Imagick::trimImage takes one parameter which is "fuzz". Quoting ImageMagick manual: "By default target must match a particular pixel color exactly. However, in many cases two colors may differ by a small amount.
/* Create the object and read the image in */
$im = new Imagick( "test.png" );
/* The background color. This is what we trim. */
$im->setImageBackgroundColor( new ImagickPixel( "rgb(213,213,213)" ) );
/* Trim the image. */
$im->trimImage( 0 );
/* Ouput the image */
header( "Content-Type: image/" . $im->getImageFormat() );
echo $im;
?>
Read more
Showing posts with label open source. Show all posts
Showing posts with label open source. Show all posts
Thursday, October 23, 2008
Wednesday, October 1, 2008
Accessing the Elements of a Form
<HTML>
<HEAD>
<TITLE>Multiform Document Example</TITLE>
<SCRIPT LANGUAGE="JavaScript"><!--
function displayFormData() {
win2=open("","window2")
win2.document.open("text/plain")
win2.document.writeln("This document has "+document.forms.length+" forms.")
var i=0;
var j=0;
for(i=0;i<document.forms.length;++i) {
win2.document.writeln("Form "+i+" has "+ document.forms[i].elements.length+" elements.")
for(j=0;j<document.forms[i].elements.length;++j) {
win2.document.writeln((j+1)+" A "+ document.forms[i].elements[j].type+" element.")
}
}
win2.document.close()
return false
}
// --></SCRIPT>
</HEAD>
<BODY>
<FORM ACTION="nothing" onSubmit="return displayFormData()">
<H2>Form 1</H2>
<P>Text field: <INPUT TYPE="TEXT" NAME="f1-1" VALUE="Sample text"></P>
<P>Password field: <INPUT TYPE="PASSWORD" NAME="f1-2"></P>
<P>Text area field: <TEXTAREA ROWS="4" COLS="30" NAME="f1-3">Text</TEXTAREA></P>
<P><INPUT TYPE="SUBMIT" NAME="f1-4" VALUE="Submit">
<INPUT TYPE="RESET" NAME="f1-5"></P>
</FORM>
<HR>
<FORM>
<H2>Form 2</H2>
<P><INPUT TYPE="CHECKBOX" NAME="f2-1" VALUE="1" CHECKED>A</P>
<P><INPUT TYPE="CHECKBOX" NAME="f2-1" VALUE="2">B</P>
<P><INPUT TYPE="CHECKBOX" NAME="f2-1" VALUE="3">C</P>
<P><INPUT TYPE="RADIO" NAME="f2-2" VALUE="1">D</P>
<P><INPUT TYPE="RADIO" NAME="f2-2" VALUE="2" CHECKED> E</P>
<P><INPUT TYPE="RADIO" NAME="f2-2" VALUE="3">F</P>
<INPUT TYPE="FILE" NAME="f2-3">
</FORM>
<HR>
<FORM>
<H2>Form 3</H2>
<INPUT TYPE="HIDDEN" NAME="f3-1">
<SELECT NAME="f3-2" SIZE="4">
<OPTION VALUE="">Item 1</OPTION>
<OPTION VALUE="">Item 2</OPTION>
<OPTION VALUE="" SELECTED>Item 3</OPTION>
<OPTION VALUE="">Item 4</OPTION>
<OPTION VALUE="">Item 5</OPTION>
</SELECT>
</FORM>
</BODY>
</HTML>
Try Online
Monday, September 29, 2008
Chromium Memory Usage
Memory Usage Backgrounder
Chromium Memory Usage
Here is some background information if you are measuring memory in Chromium.
Multi-Process Model Background
To understand Chromium's memory usage, let's understand the multi-process model. Unlike other browsers, Chromium is divided into multiple processes. When Chromium starts up, it will initially have two processes. One process is the browser process which controls the main browser functionality, and the other is the initial renderer process, which runs the WebKit rendering engine and JavaScript (V8). Each time you open a new tab in Chromium, you'll likely get a new renderer process. With typical browsing, it is common to see 5-7 chrome.exe processes active. Further, if the pages you have open contain plugins, those plugins will also execute within independent processes. All of Chromium's processes, whether it is a browser process, a renderer process, or a plugin process, will show under the Task Manager as "chrome.exe".
Here is a screenshot of what you might see from Windows Vista running Chromium:
Read more
Chromium Memory Usage
Here is some background information if you are measuring memory in Chromium.
Multi-Process Model Background
To understand Chromium's memory usage, let's understand the multi-process model. Unlike other browsers, Chromium is divided into multiple processes. When Chromium starts up, it will initially have two processes. One process is the browser process which controls the main browser functionality, and the other is the initial renderer process, which runs the WebKit rendering engine and JavaScript (V8). Each time you open a new tab in Chromium, you'll likely get a new renderer process. With typical browsing, it is common to see 5-7 chrome.exe processes active. Further, if the pages you have open contain plugins, those plugins will also execute within independent processes. All of Chromium's processes, whether it is a browser process, a renderer process, or a plugin process, will show under the Task Manager as "chrome.exe".
Here is a screenshot of what you might see from Windows Vista running Chromium:
Read more
Google Chrome Multi-process Architecture
Unlike most current web browsers, Google Chrome uses many operating system processes to keep web sites separate from each other and from the rest of your computer. In this blog post, I'll explain why using a multi-process architecture can be a big win for browsers on today's web. I'll also talk about which parts of the browser belong in each process and in which situations Google Chrome creates new processes.
1. Why use multiple processes in a browser?
In the days when most current browsers were designed, web pages were simple and had little or no active code in them. It made sense for the browser to render all the pages you visited in the same process, to keep resource usage low.
Today, however, we've seen a major shift towards active web content, ranging from pages with lots of JavaScript and Flash to full-blown "web apps" like Gmail. Large parts of these apps run inside the browser, just like normal applications run on an operating system. Just like an operating system, the browser must keep these apps separate from each other.
On top of this, the parts of the browser that render HTML, JavaScript, and CSS have become extraordinarily complex over time. These rendering engines frequently have bugs as they continue to evolve, and some of these bugs may cause the rendering engine to occasionally crash. Also, rendering engines routinely face untrusted and even malicious code from the web, which may try to exploit these bugs to install malware on your computer.
In this world, browsers that put everything in one process face real challenges for robustness, responsiveness, and security. If one web app causes a crash in the rendering engine, it will take the rest of the browser with it, including any other web apps that are open. Web apps often have to compete with each other for CPU time on a single thread, sometimes causing the entire browser to become unresponsive. Security is also a concern, because a web page that exploits a vulnerability in the rendering engine can often take over your entire computer.
It doesn't have to be this way, though. Web apps are designed to be run independently of each other in your browser, and they could be run in parallel. They don't need much access to your disk or devices, either. The security policy used throughout the web ensures this, so that you can visit most web pages without worrying about your data or your computer's safety. This means that it's possible to more completely isolate web apps from each other in the browser without breaking them. The same is true of browser plug-ins like Flash, which are loosely coupled with the browser and can be separated from it without much trouble.
2. What goes in each process?
Google Chrome creates three different types of processes: browser, renderers, and plug-ins.
Browser. There's only one browser process, which manages the tabs, windows, and "chrome" of the browser. This process also handles all interactions with the disk, network, user input, and display, but it makes no attempt to parse or render any content from the web.
Renderers. The browser process creates many renderer processes, each responsible for rendering web pages. The renderer processes contain all the complex logic for handling HTML, JavaScript, CSS, images, and so on. We achieve this using the open source WebKit rendering engine, which is also used by Apple's Safari web browser. Each renderer process is run in a sandbox, which means it has almost no direct access to your disk, network, or display. All interactions with web apps, including user input events and screen painting, must go through the browser process. This lets the browser process monitor the renderers for suspicious activity, killing them if it suspects an exploit has occurred.
Read more
1. Why use multiple processes in a browser?
In the days when most current browsers were designed, web pages were simple and had little or no active code in them. It made sense for the browser to render all the pages you visited in the same process, to keep resource usage low.
Today, however, we've seen a major shift towards active web content, ranging from pages with lots of JavaScript and Flash to full-blown "web apps" like Gmail. Large parts of these apps run inside the browser, just like normal applications run on an operating system. Just like an operating system, the browser must keep these apps separate from each other.
On top of this, the parts of the browser that render HTML, JavaScript, and CSS have become extraordinarily complex over time. These rendering engines frequently have bugs as they continue to evolve, and some of these bugs may cause the rendering engine to occasionally crash. Also, rendering engines routinely face untrusted and even malicious code from the web, which may try to exploit these bugs to install malware on your computer.
In this world, browsers that put everything in one process face real challenges for robustness, responsiveness, and security. If one web app causes a crash in the rendering engine, it will take the rest of the browser with it, including any other web apps that are open. Web apps often have to compete with each other for CPU time on a single thread, sometimes causing the entire browser to become unresponsive. Security is also a concern, because a web page that exploits a vulnerability in the rendering engine can often take over your entire computer.
It doesn't have to be this way, though. Web apps are designed to be run independently of each other in your browser, and they could be run in parallel. They don't need much access to your disk or devices, either. The security policy used throughout the web ensures this, so that you can visit most web pages without worrying about your data or your computer's safety. This means that it's possible to more completely isolate web apps from each other in the browser without breaking them. The same is true of browser plug-ins like Flash, which are loosely coupled with the browser and can be separated from it without much trouble.
2. What goes in each process?
Google Chrome creates three different types of processes: browser, renderers, and plug-ins.
Browser. There's only one browser process, which manages the tabs, windows, and "chrome" of the browser. This process also handles all interactions with the disk, network, user input, and display, but it makes no attempt to parse or render any content from the web.
Renderers. The browser process creates many renderer processes, each responsible for rendering web pages. The renderer processes contain all the complex logic for handling HTML, JavaScript, CSS, images, and so on. We achieve this using the open source WebKit rendering engine, which is also used by Apple's Safari web browser. Each renderer process is run in a sandbox, which means it has almost no direct access to your disk, network, or display. All interactions with web apps, including user input events and screen painting, must go through the browser process. This lets the browser process monitor the renderers for suspicious activity, killing them if it suspects an exploit has occurred.
Read more
Friday, September 26, 2008
Tips to Improve Joomla Performance = Fast page loading and error-free Joomla Website
When you are using the Joomla content management system, the overall site performance could be affected by various factors. Moreover, if you have many site users, the page loading speed could be influenced by the simultaneous number of MySQL database queries. In order to obtain the best results for the page loading speed (which is a key factor for the search engines rankings) and to maintain the best performance of your Joomla website, there are a few tips that could help you.
The recent studies show that Joomla is twice as fast when used with PHP 5.2.3 in comparison with PHP 4.4, as a consequence the use of the last PHP version (which is definitely improved) will always offer you the optimal Joomla performance.
If you turn on caching on the Cache tab from Joomla Global Configuration in Administration Panel, then static files or a cache of your website will be created. The file caching allows the system to find a certain page directly from hard disk and removes the delay induced by a MySQL query to retrieve the same page in the database. The speed of page loading will also be increased by enabling caching.
On the Cache tab, when enabling caching, you must not modify the default cache folder, but you can set a lower value for the cache time if you update the site contents often and a higher value if the content is changed rarely. There are also many modules from Joomla structure that support caching. It is recommended to enable caching for those modules. There are also components that improve the page caching process, such as Ircmaxell's Page Cache.This component will have visible effects on page load speed in case of website with high traffic.
Another important aspect that could affect Joomla performance is the template structure. For the best performance, you should use CSS templates and remove the unused CSS styles. The images should be optimized for web display in order to decrease the page loading time. The unused modules should be unpublished and flash modules should be avoided if they are not really necessary.
Before installing Joomla on a webserver you should test the site performance using benckmarking tools on the local computer. There are more advanced settings to modify in php.ini and .htaccess files, respectively, to increase Joomla performance, but these are specific to every joomla website, depending on its destination. In case you modify them, you should check the apache server documentation to maintain your website free of errors.
The recent studies show that Joomla is twice as fast when used with PHP 5.2.3 in comparison with PHP 4.4, as a consequence the use of the last PHP version (which is definitely improved) will always offer you the optimal Joomla performance.
If you turn on caching on the Cache tab from Joomla Global Configuration in Administration Panel, then static files or a cache of your website will be created. The file caching allows the system to find a certain page directly from hard disk and removes the delay induced by a MySQL query to retrieve the same page in the database. The speed of page loading will also be increased by enabling caching.
On the Cache tab, when enabling caching, you must not modify the default cache folder, but you can set a lower value for the cache time if you update the site contents often and a higher value if the content is changed rarely. There are also many modules from Joomla structure that support caching. It is recommended to enable caching for those modules. There are also components that improve the page caching process, such as Ircmaxell's Page Cache.This component will have visible effects on page load speed in case of website with high traffic.
Another important aspect that could affect Joomla performance is the template structure. For the best performance, you should use CSS templates and remove the unused CSS styles. The images should be optimized for web display in order to decrease the page loading time. The unused modules should be unpublished and flash modules should be avoided if they are not really necessary.
Before installing Joomla on a webserver you should test the site performance using benckmarking tools on the local computer. There are more advanced settings to modify in php.ini and .htaccess files, respectively, to increase Joomla performance, but these are specific to every joomla website, depending on its destination. In case you modify them, you should check the apache server documentation to maintain your website free of errors.
Wednesday, September 17, 2008
CHM Reader
CHM Reader is an extension to allow Firefox to read Compiled HTML (.chm) files. After installation, with "File | Open CHM File", you can open a CHM file in Firefox. With "View | Sidebar | CHM Reader" or "Ctrl-E", a sidebar that contains topics and an index of the CHM files will be shown.
Tuesday, September 2, 2008
Open Source Scripts and Programs Ajax Javascript
Thousands of open source Javascript /Ajax projects
XML parsers
Content Editors
Image processing
XML parsers
Content Editors
Image processing
Subscribe to:
Posts (Atom)
Posts
