[prev in list] [next in list] [prev in thread] [next in thread]
List: cairo-commit
Subject: [cairo-commit] [cairo-www] 5 commits - src/cookbook.mdwn src/documentation.mdwn src/dotnet-gdi-rende
From: nmartensen () freedesktop ! org (Nis Martensen)
Date: 2012-06-01 22:13:27
Message-ID: 20120601221328.00FA764B63 () annarchy ! freedesktop ! org
[Download RAW message or body]
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@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@cairographics.org>.
+
Off-site material
=================
Here is a collection of pointers to articles that have been written
commit 288415f8d445cc5f2efef5b002a3c072341946ff
Author: Nis Martensen <nis.martensen@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@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@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@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);
_______________________________________________
cairo-commit mailing list
cairo-commit@lists.cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo-commit
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic