Ink Stroke Editing via Selective Rendering

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current digital ink rendering technologies require re-rendering of all ink strokes whenever a change occurs, leading to inefficiencies in memory usage and compatibility issues across different UI frameworks, as each application must handle ink rendering functionality individually.

Innovation Solution

Implementing a platform-level container to manage natively-supported ink stroke data structures, allowing only updated ink stroke visuals to be re-rendered without re-rendering unchanged visuals, and providing accessibility to multiple applications through APIs, thus decoupling ink stroke management from individual applications and enabling flexible rendering across different UI frameworks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If all ink stroke visuals are re-rendered whenever a change occurs, then rendering consistency is maintained, but memory consumption and processing time increase significantly

Engineering Contradiction:

Improverendering consistencyVSAvoidmemory consumption

Core Design Contradiction:

ReliabilityVSLoss of energy

Solution Approach 1:

The rendering system is segmented into individual ink stroke components, each with its own data structure. Instead of re-rendering all strokes, only the specific stroke that changed is re-rendered. The container maintains separate data structures for each stroke, allowing selective updates based on change events.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system performs partial rendering by only re-rendering the specific ink stroke that has changed rather than all strokes. The rendering function receives a parameter indicating whether to render all strokes or only the changed stroke, enabling optimized partial updates.

Inventive Principle:

Principle #16Partial or excessive action

2Adaptability or versatility

If each application handles ink rendering functionality individually, then application independence is maintained, but device complexity and redundancy increase

Engineering Contradiction:

Improveapplication independenceVSAvoidrendering functionality redundancy

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

A universal platform-level container is implemented that can be accessed by multiple applications through a common API. The container provides ink stroke data structure management and rendering functionality that serves multiple applications, eliminating redundancy while maintaining application independence through the interface layer.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The platform-level container acts as an intermediary between applications and the rendering system. Applications interact with the container through a defined API rather than implementing rendering functionality directly, which reduces device complexity by centralizing rendering logic while preserving application independence.

Inventive Principle:

Principle #24Intermediary (Mediator)

3Speed

If ink stroke data structures are updated frequently, then responsiveness to user input is improved, but processing overhead increases

Engineering Contradiction:

Improveresponsiveness to user inputVSAvoidprocessing overhead

Core Design Contradiction:

SpeedVSLoss of time

Solution Approach 1:

Ink stroke data structures are prepared and maintained in advance in the platform-level container, with data structures ready for immediate update. When user input occurs, the pre-positioned data structures can be updated instantly without initialization overhead, improving responsiveness.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system performs partial updates by only processing and re-rendering the specific stroke that changed rather than all strokes. This reduces processing overhead while maintaining responsiveness to user input by focusing computational resources only on the changed element.

Inventive Principle:

Principle #16Partial or excessive action

Data Source

PatentUS10089291B2Ink stroke editing and manipulation

Publication Date: 2018.10.02 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

A platform-level container configured to hold natively-supported ink stroke data structures is maintained. The platform-level container is accessible to a plurality of different applications. An ink stroke visual corresponding to each ink stroke data structure held by the platform-level container is rendered via a display. An ink stroke change event corresponding to an ink stroke data structure held by the platform-level container is recognized. The ink stroke data structure is changed to an updated ink stroke data structure in accordance with the ink stroke change event. An ink stroke visual corresponding to the updated ink stroke data structure is rendered via the display without re-rendering ink stroke visuals corresponding to unchanged ink stroke data structures.