racket / racket/draw

Feature request: `make-bitmap` method of `dc<%>`

Open
#18 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Racket
Stars
19
Forks
24
PR merge metrics
No merged PRs in 30d

Description

I would like to request that a make-bitmap method be added to dc<%>. I would like it to behave like the existing make-bitmap function, with the following differences:

  • The backing scale is automatically inherited from the dc it is created from, and

  • it automatically chooses between make-bitmap, make-platform-bitmap, and make-screen-bitmap depending on what is most appropriate for the drawing context (if relevant).

For example, the drawing context produced by the get-dc method of canvas<%> would presumably use make-screen-bitmap to create a bitmap, while drawing contexts that don’t actually draw to bitmaps like post-script-dc% and record-dc% would just return a bitmap created with the make-bitmap function. Instances of bitmap-dc% would create bitmaps with the same properties as the currently-installed bitmap.

This would make it significantly easier for functions like blur from pict to do the right thing, avoiding bugs like racket/pict#52. I’m not sure it’s currently even possible to handle the second point with the existing interface.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing make-bitmap function and the dc<%> interface, then compare the get-dc method of canvas<%>, bitmap-dc%, post-script-dc%, and record-dc%. Done would mean a dc<%>-level make-bitmap that inherits backing scale and selects the appropriate bitmap constructor, but the issue leaves the feasibility and design of the second behavior unresolved.

Written by the indexing model from the issue text.

Assessment

Domain
computer-graphics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.