Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(1263)

Unified Diff: base/gfx/bitmap_platform_device_win.cc

Issue 9459: Make canvas code a bit more resilient to crashes.... (Closed) Base URL: svn://chrome-svn/chrome/trunk/src/
Patch Set: '' Created 12 years, 1 month ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « no previous file | base/gfx/platform_canvas_win.h » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: base/gfx/bitmap_platform_device_win.cc
===================================================================
--- base/gfx/bitmap_platform_device_win.cc (revision 4621)
+++ base/gfx/bitmap_platform_device_win.cc (working copy)
@@ -6,7 +6,6 @@
#include "base/gfx/gdi_util.h"
#include "base/logging.h"
-#include "base/process_util.h"
#include "SkMatrix.h"
#include "SkRegion.h"
#include "SkUtils.h"
@@ -99,33 +98,6 @@
*pixel |= 0xFF000000;
}
-// Crashes the process. This is called when a bitmap allocation fails, and this
-// function tries to determine why it might have failed, and crash on different
-// lines. This allows us to see in crash dumps the most likely reason for the
-// failure. It takes the size of the bitmap we were trying to allocate as its
-// arguments so we can check that as well.
-void CrashForBitmapAllocationFailure(int w, int h) {
- // The maximum number of GDI objects per process is 10K. If we're very close
- // to that, it's probably the problem.
- const int kLotsOfGDIObjs = 9990;
- CHECK(GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS) < kLotsOfGDIObjs);
-
- // If the bitmap is ginormous, then we probably can't allocate it.
- // We use 64M pixels = 256MB @ 4 bytes per pixel.
- const int64 kGinormousBitmapPxl = 64000000;
- CHECK(static_cast<int64>(w) * static_cast<int64>(h) < kGinormousBitmapPxl);
-
- // If we're using a crazy amount of virtual address space, then maybe there
- // isn't enough for our bitmap.
- const int64 kLotsOfMem = 1500000000; // 1.5GB.
- scoped_ptr<process_util::ProcessMetrics> process_metrics(
- process_util::ProcessMetrics::CreateProcessMetrics(GetCurrentProcess()));
- CHECK(process_metrics->GetPagefileUsage() < kLotsOfMem);
-
- // Everything else.
- CHECK(0);
-}
-
} // namespace
class BitmapPlatformDeviceWin::BitmapPlatformDeviceWinData
@@ -263,16 +235,16 @@
SkBitmap bitmap;
// CreateDIBSection appears to get unhappy if we create an empty bitmap, so
- // we just expand it here.
- if (width == 0)
+ // just create a minimal bitmap
+ if ((width == 0) || (height == 0)) {
width = 1;
- if (height == 0)
height = 1;
+ }
- BITMAPINFOHEADER hdr;
+ BITMAPINFOHEADER hdr = {0};
CreateBitmapHeader(width, height, &hdr);
- void* data;
+ void* data = NULL;
HBITMAP hbitmap = CreateDIBSection(screen_dc,
reinterpret_cast<BITMAPINFO*>(&hdr), 0,
&data,
@@ -282,8 +254,11 @@
// bitmap here. This will cause us to crash later because the data pointer is
// NULL. To make sure that we can assign blame for those crashes to this code,
// we deliberately crash here, even in release mode.
- if (!hbitmap)
- CrashForBitmapAllocationFailure(width, height);
+ if (!hbitmap) {
+ DWORD error = GetLastError();
+ NOTREACHED() << "CreateDIBSection Failed. Error: " << error << "\n";
+ return NULL;
+ }
bitmap.setConfig(SkBitmap::kARGB_8888_Config, width, height);
bitmap.setPixels(data);
« no previous file with comments | « no previous file | base/gfx/platform_canvas_win.h » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698