[cairo-commit] [cairo-www] 5 commits - src/cookbook.mdwn src/documentation.mdwn src/dotnet-gdi-rendering.mdwn src/samples
Nis Martensen
nmartensen at freedesktop.org
Fri Jun 1 15:13:27 PDT 2012
src/cookbook.mdwn | 1
src/documentation.mdwn | 10 +++++++
src/dotnet-gdi-rendering.mdwn | 9 +++---
src/samples/dotnet-gdi-rendering.mdwn | 47 ----------------------------------
4 files changed, 16 insertions(+), 51 deletions(-)
New commits:
commit e07062d8efbb847d5e11d342469e886a6df15a10
Author: Nis Martensen <nis.martensen at web.de>
Date: Sat Jun 2 00:06:03 2012 +0200
documentation: add minimal instructions for submitting website changes
diff --git a/src/documentation.mdwn b/src/documentation.mdwn
index f5ebebf..fdca2e6 100644
--- a/src/documentation.mdwn
+++ b/src/documentation.mdwn
@@ -34,6 +34,16 @@ Other information that might be of interest:
* [[Building]]: Various recipes for compiling Cairo sources on different platforms, and with different goals
+
+Editing this Website
+--------------------
+Currently the cairo website can only be edited via git.
+You can get the sources by running
+
+ git clone git://cairographics.org/git/cairo-www
+
+To submit changes, please send patches to <mailto:cairo at cairographics.org>.
+
Off-site material
=================
Here is a collection of pointers to articles that have been written
commit 288415f8d445cc5f2efef5b002a3c072341946ff
Author: Nis Martensen <nis.martensen at web.de>
Date: Fri Jun 1 23:41:41 2012 +0200
cookbook: hook up dotnet-gdi-rendering
... so that it can still be accessed from somewhere.
diff --git a/src/cookbook.mdwn b/src/cookbook.mdwn
index 5c6e54f..66bb541 100644
--- a/src/cookbook.mdwn
+++ b/src/cookbook.mdwn
@@ -4,6 +4,7 @@
* [[Rounded_rectangles|roundedrectangles]]
* [[Using_Win32_Quickstart|win32quickstart]]
+* [[.NET GDI rendering|dotnet-gdi-rendering]]
* [[Using_Perl_Cairo_module|perl_cairo_module]]
* [[Rendering_SVG_using_librsvg_in_Python|librsvgpython]]
* [[Converting_cairo_code_from_C_to_Python_or_Haskell_and_back|ConvertCtoPyAndBack]]
commit 58252732fc0316bdca576f56a6ce3be4c98c92be
Author: Nis Martensen <nis.martensen at web.de>
Date: Fri Jun 1 23:08:52 2012 +0200
dotnet-gdi-rendering: minor formatting improvement
diff --git a/src/dotnet-gdi-rendering.mdwn b/src/dotnet-gdi-rendering.mdwn
index 02c7f8b..c01a67a 100644
--- a/src/dotnet-gdi-rendering.mdwn
+++ b/src/dotnet-gdi-rendering.mdwn
@@ -29,9 +29,9 @@ Using GDI+ Bitmap as surface can be as simple as that (given in managed C++):
g->ReleaseHdc(hdc);
-This works quite well but has one big disadvantage: cairo\_ win32\_surface_create always returns a 24bit surface. So what if we have a bitmap with an alpha channel (like a png image we loaded and want to add something to it)? With the code above the alpha channel used in your cairo commands is lost.
+This works quite well but has one big disadvantage: `cairo_win32_surface_create()` always returns a 24bit surface. So what if we have a bitmap with an alpha channel (like a png image we loaded and want to add something to it)? With the code above the alpha channel used in your cairo commands is lost.
-One could create a 32bit DIB surface (using cairo\_win32\_surface\_create\_with\_dib), but that creates a **separate** surface, which needs to be merged later to your actual target. Using an API like AlphaBlend (via pinvoke) produces exactly the same result as in the code above. So this is no help either.
+One could create a 32bit DIB surface (using `cairo_win32_surface_create_with_dib()`), but that creates a **separate** surface, which needs to be merged later to your actual target. Using an API like AlphaBlend (via pinvoke) produces exactly the same result as in the code above. So this is no help either.
The solution for this dilemma is an image surface (e.g. you get an image surface when you load png images in cairo).
commit 6fb4029aefcadb564c8eb1c8e741ea8c613d67d7
Author: Nis Martensen <nis.martensen at web.de>
Date: Fri Jun 1 23:03:08 2012 +0200
dotnet-gdi-rendering: delete copy in samples/ folder
While the dotnet-gdi-rendering example contains sample code, it does not
relate to a drawing sample and thus does not belong in the src/samples/
directory. Since we have another copy in src/, we do not lose anything
by deleting it.
diff --git a/src/samples/dotnet-gdi-rendering.mdwn b/src/samples/dotnet-gdi-rendering.mdwn
deleted file mode 100644
index 02c7f8b..0000000
--- a/src/samples/dotnet-gdi-rendering.mdwn
+++ /dev/null
@@ -1,47 +0,0 @@
-Using GDI+ Bitmap as surface can be as simple as that (given in managed C++):
-
- // Create the target bitmap to draw to.
- Drawing::Bitmap contentBitmap= new Drawing::Bitmap(Width, Height);
-
- // Create a Graphics object to have a device context we can pass to cairo.
- Graphics^ g = Graphics::FromImage(contentBitmap);
- g->SmoothingMode = SmoothingMode::HighQuality;
-
- // Do some drawing in GDI+ to have some initial content, like:
- // Fill interior.
- Brush^ brush = gcnew SolidBrush(Color::FromArgb(191, 1, 0, 0));
- g->FillPath(brush, innerPath);
- delete brush;
-
- // Get the device context handle from this graphics object and create a Win32 cairo surface from it.
- IntPtr hdc= g->GetHdc();
- cairo_surface_t* surface= cairo_win32_surface_create((HDC) hdc.ToPointer());
-
- // For drawing we need a cairo context.
- cairo_t* cr= cairo_create(surface);
-
- // Now you are ready to draw to that using any of the cairo calls.
- ...
-
- // Don't forget the cleanup.
- cairo_destroy(cr);
- cairo_surface_destroy(surface);
-
- g->ReleaseHdc(hdc);
-
-This works quite well but has one big disadvantage: cairo\_ win32\_surface_create always returns a 24bit surface. So what if we have a bitmap with an alpha channel (like a png image we loaded and want to add something to it)? With the code above the alpha channel used in your cairo commands is lost.
-
-One could create a 32bit DIB surface (using cairo\_win32\_surface\_create\_with\_dib), but that creates a **separate** surface, which needs to be merged later to your actual target. Using an API like AlphaBlend (via pinvoke) produces exactly the same result as in the code above. So this is no help either.
-
-The solution for this dilemma is an image surface (e.g. you get an image surface when you load png images in cairo).
-
- // Instead of getting an HDC and and use cairo_win32_surface we get directly
- // to the pixels in the bitmap and create the image surface from that.
- Imaging::BitmapData^ bitmapData= contentBitmap->LockBits(Drawing::Rectangle(0, 0, Width, Height),
- Imaging::ImageLockMode::ReadWrite, contentBitmap->PixelFormat);
- unsigned char* data= (unsigned char*) bitmapData->Scan0.ToPointer();
- cairo_surface_t* surface= cairo_image_surface_create_for_data(data, CAIRO_FORMAT_ARGB32, Width, Height,
- bitmapData->Stride);
-
- // The rest is the same as above, except we have to unlock the bits after we finished drawing.
- contentBitmap->UnlockBits(bitmapData);
commit c658cf32772e9fcba3964356285c90c2f27d2721
Author: Nis Martensen <nis.martensen at web.de>
Date: Fri Jun 1 22:58:43 2012 +0200
dotnet-gdi-rendering: sync both copies
There are two copies of the dotnet-gdi-rendering example. The one in
src/ was created first, the one in src/samples/ was created afterwards
and then modified slightly.
Bring both copies in sync again.
diff --git a/src/dotnet-gdi-rendering.mdwn b/src/dotnet-gdi-rendering.mdwn
index 5dd4ba7..02c7f8b 100644
--- a/src/dotnet-gdi-rendering.mdwn
+++ b/src/dotnet-gdi-rendering.mdwn
@@ -29,18 +29,19 @@ Using GDI+ Bitmap as surface can be as simple as that (given in managed C++):
g->ReleaseHdc(hdc);
-This works quite well but has one big disadvantage: cairo_win32_surface_create always returns a 24bit surface. So what if we have a bitmap with an alpha channel (like a png image we loaded and want to add something to it)? With the code above the alpha channel used in your cairo commands is lost.
+This works quite well but has one big disadvantage: cairo\_ win32\_surface_create always returns a 24bit surface. So what if we have a bitmap with an alpha channel (like a png image we loaded and want to add something to it)? With the code above the alpha channel used in your cairo commands is lost.
-One could create a 32bit DIB surface (using cairo_win32_surface_create_with_dib), but that creates a *separate* surface, which needs to be merged later to your actual target. Using an API like AlphaBlend (via pinvoke) produces exactly the same result as in the code above.
+One could create a 32bit DIB surface (using cairo\_win32\_surface\_create\_with\_dib), but that creates a **separate** surface, which needs to be merged later to your actual target. Using an API like AlphaBlend (via pinvoke) produces exactly the same result as in the code above. So this is no help either.
-The solution to this dilemma is an image surface (e.g. you get an image surface when you load png images in cairo).
+The solution for this dilemma is an image surface (e.g. you get an image surface when you load png images in cairo).
// Instead of getting an HDC and and use cairo_win32_surface we get directly
// to the pixels in the bitmap and create the image surface from that.
Imaging::BitmapData^ bitmapData= contentBitmap->LockBits(Drawing::Rectangle(0, 0, Width, Height),
Imaging::ImageLockMode::ReadWrite, contentBitmap->PixelFormat);
unsigned char* data= (unsigned char*) bitmapData->Scan0.ToPointer();
- cairo_surface_t* surface= cairo_image_surface_create_for_data(data, CAIRO_FORMAT_ARGB32, Width, Height, bitmapData->Stride);
+ cairo_surface_t* surface= cairo_image_surface_create_for_data(data, CAIRO_FORMAT_ARGB32, Width, Height,
+ bitmapData->Stride);
// The rest is the same as above, except we have to unlock the bits after we finished drawing.
contentBitmap->UnlockBits(bitmapData);
More information about the cairo-commit
mailing list