danro

#-webkit-web-inspector #toolbar {
  background: #cdcdcd !important;
  height: 36px !important;
}
#-webkit-web-inspector #main {
  top: 36px !important;
}
#-webkit-web-inspector .toolbar-item.elements:hover:after {
  content: "elements";
  z-index: 9999;

KrofDrakula

Rendering performance on WebKit

Please send any feedback on this article to Klemen Slavič

UPDATE: I'm currently in the process of updating the article, as my assumptions about the inner workings of WebKit are incorrect. I will update this article with the relevant facts and provide concrete information in place of my guesstimates below.

I've recently stumbled upon an interesting discovery regarding image rendering performance in most WebKit browsers. Namely, I've been developing a sprite animation component to implement a GIF animation replacement with better compression and performance, where I noticed that some animations appeared to be janky when using multi-frame spritesheets and clipping rectangles. Here's what I found out.

But first, a quick rundown of the basic functioning of the WebKit engine as I understand it.

stolsma

These instructions work for the Raspberry Pi running Raspbian (hard float) and create a hardware optimized version of NodeJS for the Raspberry PI, (and include a working install and NPM!!!):

1. Install Raspbian - http://www.raspberrypi.org/downloads

2. Install the necessary dependecies:

sudo apt-get install git-core build-essential

(If you just installed git then you need to administer your git identity first, else adding the patches below will fail!!!)

simX

sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES;
sudo defaults delete /Library/Preferences/com.apple.windowserver DisplayResolutionDisabled;

// by the way, you need to logout and log back in for this to take effect.  Or at least that's what
// Quartz Debug says.  Who knows, maybe it's lying?

// P.S. Go to [Apple menu --> System Preferences --> Displays --> Display --> Scaled] after logging
// back in, and you'll see a bunch of "HiDPI" resolutions in the list to choose from.

david-mark

Forget AMD and that's straight from the source. Sorry for the long build-up on the history, but if I'm to convince you to forget this non-technology, I think it's best you know where it came from. For those in a hurry, the executive summary is in the subject line. ;)

In Spring of 2009, I rewrote the Dojo loader during a requested renovation of that project. The primary pattern used to make it more practical was:

dojo.provide('foo', ['bar1', 'bar2'], function() {

[module code]

});

Munter

#!/bin/sh
set -o errexit

PNGS=`find . -iname "*.png"`
JPGS=`find . -iname "*.jpg"`
TMP1="_TMP1.PNG"
TMP2="_TMP2.PNG"

echo "Optimizing PNG"
for PNG in ${PNGS}

jakearchibald

document.body.addEventListener('error', function(event) {
	if ( event.target.nodeName.toLowerCase() == 'img' ) {
		// an image on the page failed to load
	}
}, true);

nimbupani

---
layout: default
---

<div class="blog-index">  
  {% assign post = site.posts.first %}
  {% assign content = post.content %}
  {% include post_detail.html %}
</div>

touv

#!/bin/sh
##3.5...10...15...20...25...30...35...40...45...50...55...60...65...70...75...80
## 
##  Debian / Linux / Ubuntu / LSB
##  Startup script for Express / Node.js application with the forever module
##
##
##  A modification of "init.d.lsb.ex" by Nicolas Thouvenin 
##
##

danpaluska

#!/bin/bash

# ffmpeg -i movie.mov -r 1 fooframes/frames%05d.jpg
# extract 1 frame for every second of the movie...

mkdir IIRframes;

let "frames=4243/2"
echo $frames
cp WSPC0001.JPG IIRframes/new.jpg